> The dataset contains about 200 hours of paired audio and MIDI recordings from ten years of International Piano-e-Competition. The MIDI data includes key strike velocities and sustain/sostenuto/una corda pedal positions. Audio and MIDI files are aligned with ∼3 ms accuracy and sliced to individual musical pieces, which are annotated with composer, title, and year of performance. Uncompressed audio is of CD quality or higher (44.1–48 kHz 16-bit PCM stereo).
Wow. That's some high quality archive. I have never encountered anything better. Pity the performer isn't listed. And the competition's web site is defunct.
Chrome doesn't use hardware acceleration for decoding any image codecs-- not for JPEG or WebP or AVIF. It has some code for it (using VA-API), but it's disabled by default. Hardware video decoders are generally hard to use for image decoding tasks.
Safari appears to be the only shipping browser using hardware decoding for JPEG and HEIF (HEVC based images). This is probably because vertical integration lets them make the decoders appropriate for image use.
Also, "AVIF video" is incorrect. AVIF is the image codec based on AV1 intra frames.
AVIF supports regular AV1 videos, there is no intra-only constraint. You can try this yourself with any AV1 video:
ffmpeg -i input.webm -c:v copy output.avif
You are right about Firefox and Chrome not using hardware decoding though, as such an AVIF video plays back poorly. And Chrome refuses to load an AVIF larger than 256 MB on my machine.
No quality compromise/degradation is something I have had this industry, including especially OpenAI, claim multiple times in the past and I have more than once been able to verify that it was in fact not the case. Examples being gpt-3.5-turbo vs text-davinci-003, GPT-4-Turbo and all the other post training checkpoints they had under one name (which was a major bug bear for me back then witnessing degradations with no naming change, industry got better in transparent checkpoint naming since), Opus 4.6 Fast Mode (which just was faster by skipping much of the required work), etc.
Same for massive performance differences in the way providers like Cerebras, Groq, etc. have deployed models including K2.6 on Cereberas specifically. Massive deltas in tool call and overall quality despite there being far more clarity in open weight vs proprietary model deployment.
The AA suite graph with that animation is the only time in either post that absolute parity is being asserted and I'd be amazed if that was the case, but am doubtful why their phrasing is so cagey.
Why not assert full parity in writing? It "performs the same (within run-to-run variance) across all evals that Sol has been tested with" is very different to "no quality compromise/degradation", the later allowing for a lot more wiggle room and interpretation in what evals you use to assess that, what quality truly means, etc., the former meaning identical in all situations.
Could also be a language barrier here in fairness, maybe this phrasing is more iron clad than I give them credit, but especially with OpenAI, I have seen enough checkpoints asserted as unchanged in "quality" to where I am skeptical. Ironically, I never saw that with Anthropic (which has gotten far more heat for degradation accusations) while a model was deployed with one exception in mid-late April this year. Pure speculation, but believe it wasn't noticed much before "agentic coding" became more popular, because chat output is far more subjective without a rating framework vs code passing which can be an objective metric with more potential for frustration.
The problem is the compromise is probably based on their tests for key things, but for the rest of us, it means changing how we talk to the model or the flow we use to adjust for quirks, but then its fully about the same.
No one claimed gpt-3.5-turbo doesn't have any degradation over davinci-003. In fact it was quite obvious that gpt-3.5 had way less knowledge but more post trained to be helpful.
That quite strong "no one" surprised me so I checked and looking through a few blog posts from back then, they did advertise gpt-3.5-turbo as a straight up improvement and, once text-davinci-003 was to be deprecated, the instruct tuned variant as the drop in replacement [0]. If anything, they did not just promise similar performance but actually an improvement ("our best model") when compared to text-davinci-003:
> It’s also our best model for many non-chat use cases—we’ve seen early testers migrate from text-davinci-003 to gpt-3.5-turbo with only a small amount of adjustment needed to their prompts.
That's why I still remember this so well, they claimed one model to be their best and a straight up drop-in during deprecation when in my (back then even more amateurish then today) testing this was plainly not the case. A model cannot be "best" if it's measurably worse in many situations, then what was still available at the time.
There's probably some quantization and other processing needed to get Sol to fit on a Celebras chip, so it's not an exact 1:1 copy of the Sol model running on Nvidia GPUs, because it's not running on GPUs doing abstract math calculations anymore, so they can run benchmarks at them and say it's similar enough, but no one believes in benchmarks in this new field of performance that's more computer astrology than computer science.
Gotta build some personal benchmarks if you don’t trust the public ones. But the well-known public ones, despite their flaws, are generally high signal on model intelligence.
It’s suspicious that they repeat “without any quality compromise” instead of just outright saying it’s the exact same model. It’s like a motel that insists they have clean beds.
- it's easy to prompt an LLM to do it for you, especially if you're targeting a pre-existing runtime like CLR or transpiling to another language. previously you'd have to grind out the parser and compiler for a new language, but a lot of that work is mechanical
- "I want a language that works a little differently"
- programming language theory (PLT), generally
- languages are tools. the authors should explain what their languages are best suited for
- Obj C and C++ were both developed around the same time as extensions of C. Obj C was focused on message passing and Smalltalk's object system, while C++ was focused on adding as many abstractions as possible to C. Neither language has good support for avoiding null pointer dereferences, one of the primary things Swift addresses with its richer type system and Optionals.
BitTorrent's bencoding format, used in .torrent files, effectively uses netstrings-- but without the trailing commas, so it uses "5:hello" to represent filenames and similar.
It's not really a big problem. You should be storing arbitrary binary strings as blobs (and length() works properly with them), but the underlying encoding is nearly identical: https://www.sqlite.org/fileformat.html#record_format
Then DBMS should not allow to save a string that would make some function return wrong results. Either truncate with a warning on INSERT (MySQL approach) or better throw an error.
Note that this breaks a lot of core functionality unless you CAST(s as TEXT) before you use it, eg iirc LIKE won’t work. Then you’re back to the same problem.
if you happen to regenerate your protos 5 times in an hour you'll get ratelimited
it's a very frustrating system. you should spend a modicum of effort figuring out how to generate your things locally yourself instead, be that docker, arcane wasm...
> The dataset contains about 200 hours of paired audio and MIDI recordings from ten years of International Piano-e-Competition. The MIDI data includes key strike velocities and sustain/sostenuto/una corda pedal positions. Audio and MIDI files are aligned with ∼3 ms accuracy and sliced to individual musical pieces, which are annotated with composer, title, and year of performance. Uncompressed audio is of CD quality or higher (44.1–48 kHz 16-bit PCM stereo).
reply