3 ms·

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’v

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.

whazor 4mo ago
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?
- vessenes 4mo ago
  Oh the project seems cool, no doubt. I'm talking more about text like: > # 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.

whazor 4mo ago

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?

vessenes 4mo ago
Oh the project seems cool, no doubt. I'm talking more about text like: > # 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.