These modern readmes written by claude have this unusual combination of density and lack of information at the same time that I think is pretty interesting. I’ve generated many of them myself, and they largely read the same to me, without many of the distinctive “load-bearing” vocabulary tics that we see in so many places.
They seem to contain a mix of subject matter expert jargon and often some words that are created during the course of coding and end up encapsulating concepts, but it makes reading the documentation liminal — it’s like reading a tech spec from an alien. And I suppose it is, after all, a tech spec from an alien.
I think what I find both interesting and difficult and annoying (and, and, and) about them is that they fail to have a theory of mind for the reader — they are essentially the slightly manic notes one leaves for oneself after a 4 day coding binge, tarted up in markdown and published.
I’ve been experimenting with asking for documentation that specifies a reader and requests a theory of mind about that reader being applied to documentation, and it’s very helpful, but I don’t think I quite have it nailed yet. And I don’t think I understand why it is that these models, which have ingested an immense amount of technical documentation, still write like this.
The goal is in the first paragraph: "aim was to let consumer gear that can't bitstream TrueHD Atmos render real object-based Atmos with height."
Summary is also clear: ffmpeg doesnt have channel coupling and proprietary cryptographic blocks it.
I was once wondering what would be the problem of doing such a project. Now it's clear to me what problems I would run into and I don't have to burn my tokens.
> # Why It Can't Fully Work
> # Wall 2 — EMDF keyed authentication (the decisive one)
> coregraft = a real Dolby core + our metadata → Dolby Surround. The metadata is rejected too, and we traced it to the EMDF emdf_protection field, which is a keyed authentication code, not a computable checksum:
or
> EMDF container (ETSI TS 102 366 Annex H) — wraps OAMD (id 11) + JOC (id 14) with the emdf_protection field, carried in the E-AC-3 audio-block skip field exactly where real Dolby streams put it (recomputing frmsiz + crc2).
These are I think (not being a Dolby or Audio expert) a mix of exactly what I was talking about. Dense / jargony and also weirdly low information at the same time.
i'm curious to see how it works for like linux support. What if you could toss like little raspberry pi's or something on speakers....and make your own DIY object sound system? haha
I think this might be possible with some of the linux sound projects...
that would be amazing.
Sad this doesn't work fully with atmost yet.. but it's all so young/new.
Seriously. I'm browsing various DYI smart speakers[1] solutions for quite a while and they all seem to have so many downsides I'm almost tempted to pull a trigger on something off the shelf :/
[1] as in speakers, not surveillance machines, speakers, somethings in all my rooms to play music or announcements on.
Why EAC3 compressed audio instead of uncompressed PCM in Dolby MAT like an Apple TV?
E-ARC has the bandwidth for 32 channel/object uncompressed Atmos no need to do EAC3 compression. This is why Apple TV and Windows use Dolby MAT uncompressed, not lossy and more direct.
You can decode TrueHD to PCM + metadata then just send out in Dolby MAT although would be limited to 44/16bit but then so is EAC3 I believe. True HD can go higher sampling and bit rates over E-ARC since it's compressed and why it's used.
Only reason to use EAC3 is to fit over lower bandwidth ARC instead of EARC, my LG tv will convert/compress Dolby MAT uncompressed from Apple TV to EAC3 DD+ if EARC is disabled and it falls back to ARC due to bandwidth constraints.
> This project includes code ported / adapted from Cavern, whose licence is non-commercial and share-alike and states that any project including the code remains bound by its terms. Accordingly the entire repository is released under the Cavern licence (see LICENSE), not MIT
Finally a project where people understand that running something through and LLM doesn't strip that something of its copyright. Kudos!
These modern readmes written by claude have this unusual combination of density and lack of information at the same time that I think is pretty interesting. I’ve generated many of them myself, and they largely read the same to me, without many of the distinctive “load-bearing” vocabulary tics that we see in so many places.
They seem to contain a mix of subject matter expert jargon and often some words that are created during the course of coding and end up encapsulating concepts, but it makes reading the documentation liminal — it’s like reading a tech spec from an alien. And I suppose it is, after all, a tech spec from an alien.
I think what I find both interesting and difficult and annoying (and, and, and) about them is that they fail to have a theory of mind for the reader — they are essentially the slightly manic notes one leaves for oneself after a 4 day coding binge, tarted up in markdown and published.
I’ve been experimenting with asking for documentation that specifies a reader and requests a theory of mind about that reader being applied to documentation, and it’s very helpful, but I don’t think I quite have it nailed yet. And I don’t think I understand why it is that these models, which have ingested an immense amount of technical documentation, still write like this.
The goal is in the first paragraph: "aim was to let consumer gear that can't bitstream TrueHD Atmos render real object-based Atmos with height."
Summary is also clear: ffmpeg doesnt have channel coupling and proprietary cryptographic blocks it.
I was once wondering what would be the problem of doing such a project. Now it's clear to me what problems I would run into and I don't have to burn my tokens.
What answers are actually unclear for you?
Oh the project seems cool, no doubt.
I'm talking more about text like:
or These are I think (not being a Dolby or Audio expert) a mix of exactly what I was talking about. Dense / jargony and also weirdly low information at the same time.this is amazing :)
i'm curious to see how it works for like linux support. What if you could toss like little raspberry pi's or something on speakers....and make your own DIY object sound system? haha
I think this might be possible with some of the linux sound projects...
that would be amazing.
Sad this doesn't work fully with atmost yet.. but it's all so young/new.
This is probably a valid use case for mythos haha
Seriously. I'm browsing various DYI smart speakers[1] solutions for quite a while and they all seem to have so many downsides I'm almost tempted to pull a trigger on something off the shelf :/
[1] as in speakers, not surveillance machines, speakers, somethings in all my rooms to play music or announcements on.
Why EAC3 compressed audio instead of uncompressed PCM in Dolby MAT like an Apple TV?
E-ARC has the bandwidth for 32 channel/object uncompressed Atmos no need to do EAC3 compression. This is why Apple TV and Windows use Dolby MAT uncompressed, not lossy and more direct.
You can decode TrueHD to PCM + metadata then just send out in Dolby MAT although would be limited to 44/16bit but then so is EAC3 I believe. True HD can go higher sampling and bit rates over E-ARC since it's compressed and why it's used.
Only reason to use EAC3 is to fit over lower bandwidth ARC instead of EARC, my LG tv will convert/compress Dolby MAT uncompressed from Apple TV to EAC3 DD+ if EARC is disabled and it falls back to ARC due to bandwidth constraints.
What a rare breath of sanity:
> This project includes code ported / adapted from Cavern, whose licence is non-commercial and share-alike and states that any project including the code remains bound by its terms. Accordingly the entire repository is released under the Cavern licence (see LICENSE), not MIT
Finally a project where people understand that running something through and LLM doesn't strip that something of its copyright. Kudos!