eac3to - audio conversion tool

13th June 2019, 23:17

I often use eac3to to demux BD streams. In the past I've noted a common delay of just above 21ms (there's a remaining delay of less than 1ms) when dealing with DTSHD track transcoding (eg. DTSHD > FLAC). At the time, I read up on this a fair bit and did some of my own testing, eventually concluding that a simple "-21ms" parameter would be ideal when dealing with DTSHD in this way.

There's plenty of discussion about this, but a lot of it seems related to specific issues and I can't find anything conclusive about whether or not this is the right way to approach this. I'm not sure if there is a "correct" way to do this (for instance a trim based on samples / frames to make it align perfectly or some internal function that does this), or if I should be touch this value at all. I believe it's an encoder delay (and not a decoder delay, but I could be wrong) and so it stands to reason that if this is true, perhaps some BDs have been authored with compensation for this delay in mind.

I was wondering if the way I'm handling it is the correct procedure, or is there a better way?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Switch to Hybrid Mode Threaded Mode

13th June 2019, 23:17	#11 \| Link
thecoreyburton Guest Posts: n/a	I often use eac3to to demux BD streams. In the past I've noted a common delay of just above 21ms (there's a remaining delay of less than 1ms) when dealing with DTSHD track transcoding (eg. DTSHD > FLAC). At the time, I read up on this a fair bit and did some of my own testing, eventually concluding that a simple "-21ms" parameter would be ideal when dealing with DTSHD in this way. There's plenty of discussion about this, but a lot of it seems related to specific issues and I can't find anything conclusive about whether or not this is the right way to approach this. I'm not sure if there is a "correct" way to do this (for instance a trim based on samples / frames to make it align perfectly or some internal function that does this), or if I should be touch this value at all. I believe it's an encoder delay (and not a decoder delay, but I could be wrong) and so it stands to reason that if this is true, perhaps some BDs have been authored with compensation for this delay in mind. I was wondering if the way I'm handling it is the correct procedure, or is there a better way?