Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

25% Positive

Analyzed from 394 words in the discussion.

Trending Topics

#documentation#why#project#uncompressed#dolby#mat#arc#reader#don#atmos

Discussion (4 Comments)Read Original on HackerNews

vessenes•about 4 hours ago
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•about 3 hours 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?

SigmundA•about 2 hours ago
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.

gspr•about 3 hours ago
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!