foobarqux

It's called the "Great Leap Forward" https://en.wikipedia.org/wiki/Human_evolution#Transition_to_...

> If we sorted through all those new apps and ignored all the crap, I'm pretty sure we would find an overall increase in actually useful apps. I just shipped a new app myself, and I think it's useful, and I wouldn't have finished mine without AI assistance.

App store revenue actually decreased! That suggests that the apps are largely not useful, unless you make the implausible assumption that nearly none of them are charging money.

https://www.ft.com/content/e5533f32-e4c2-4ce1-9d2e-a831e9654...

This is like 2x realtime on M1 vs 60x on fluidaudio with parakeet.

There is a pre-existing transcription CLI app with the same name.

https://github.com/finnvoor/yap

You seem to be saying that you would upvote an empty article (or a gibberish article) with the title "Jacobian Conjecture Counterexample", is that right?

In what way is it interesting compared to the myriad of other posts on this topic that has content you can understand?

The rush project page on Github itself says it is only "slightly" faster.

But bashenumerate doesn't do that? The parent is saying you should zsh shortloops instead of bashenumerate not zsh shortloops instead of xargs.

Yes that's the obvious thing to do and why straightforward variants of known tests would also be treated as contaminated by anyone being even somewhat rigorous.

I don't know why the standard is is to be sure that it is happening versus it being a plausible risk of making the results useless.

Thanks!

I use fluidaudiocli and it's unfortunate that it doesn't support streaming (e.g. from a named pipe); that would have been an easy workaround to both the pipelining problem and the faster-decoder problem.

The difference using an mp3 seems to be smaller: yap seems to use about the same time but fluidaudio seems to take twice as long. Do you happen to know why?

Thanks, I didn't see vanch007 version at first (only ~30 downloads), I usually look at mlx-community. For the size I was looking at the wrong model (TTS not transcribe-diarize), thanks for the corrections.

If you want to use this on the CLI: https://github.com/finnvoor/yap.

Supports SRT/TXT/VTT or JSON-with-optional-word-level-timestamps output and progress meter.

Also it can transcribe live system audio.

Just tried test using yap on a single ~1hr mp3: yap/Speechanalyzer is about 50% slower than fluidaudio on M1. yap interface is nicer though.

https://github.com/finnvoor/yap

16GB! (edit: this is wrong, I was looking at TTS, the transcribe model is 1.7GB). Compared to Parakeet 2.3GB (but no diarization).

Also doesn't seem to be tailored to Apple hardware (i.e. no MLX or ANE variant/implementation)

Fluidaudio implements Parakeet on ANE. I'd like to know how SpeechAnalyzer compares in speed.

https://github.com/FluidInference/FluidAudio

108 dB is the proposed FAA allowable pressure at the surface of the earth. They didn't come up with this number arbitrarily they did it with consultation with the supersonic plane companies and if those companies could achieve much less than 108dB then the proposed limit would be lower.

Obviously it is assumed we are talking about frequencies in the range of the audio spectrum (which a sonic boom is). Your point has nothing to do with the dB scale.

Where is this claim?

They are in fact the same. 108dB loud.

The initial boom is less than a second but it's like standing right next to the leafblower (not across the street) and is accompanied a lasting thundering-noise which is also extremely loud.

There is a substantial noise beyond the initial boom which is very loud even relative to the main boom. But even just a half second of a car horn going off right next to you every so often is intolerable.

> It’s not accurate to convert .1 psf to dB because it’s an impulsive shape, not a continuous tone. And human loudness perception depends on how smooth (low frequency) the shape is

Sorry can you explain more? It's just the definition of dB (?)

And it's less impulsive than you imagine, go to youtube to listen to the sonic boom + continuous roar.

The FAA has no criteria about the "texture" of the sound and there is no reason to believe the allowed planes will differ substantially in this respect compared to every other supersonic aircraft in the past.

The proposed limit is around the level of standing right next to a leaf blower.

0.11 pound per square foot is what is being proposed. That's 108 decibels. Which is between standing next to a lawn mower and standing next to a car horn. I don't see how anyone will tolerate that in practice.

https://www.omnicalculator.com/physics/db

What is Rogue-like about this?

llm-cmd-comp is the best of these types of tools.

https://github.com/CGamesPlay/llm-cmd-comp

....

     function repology() {
         curl -L --user-agent 'hackernews' \
             "http://repology.org/api/v1/project/$@"
    }

What is a better option?

I'm saying you can go even further and automate the entire thing using LLMs/agents, it is pretty much the ideal use case: you have a black-box reference implementation to test against; descriptive documentation for what the functions should do; some explicitly supplied examples in the documentation; and the ability to automatically create an arbitrary number of tests.

So not only do you have a closed loop system that has objective/automatic pass-fail criteria you also don't even have to supply the instructions about what the function is supposed to do or the test cases!

Obviously this isn't going to be 100% reliable (especially for edge cases) but you should be able to get an enormous speed up. And in many cases you should be able to supply the edge case tests and have the LLM fix it.

(Codex is still free for the next few days if you want to try their "High"/"Extra high" thinking models)