Should audio last (almost) as long as video?

[pipefan413]

Is it an up to date version of eac3to? I think at least the older ones needed some extra library to properly decode dts hd ma. With newer ones idk, but I know ffmpeg decodes DTS-HD MA perfectly, at least in current versions.

Yup, 3.34!

Started testing now. I'm trying to find documentation to confirm whether it's even possible to use ffmpeg to split .dtshd to mono WAVs (equivalent to the "wavs" option in eac3to) but can't seem to find it. If not, I might have to just convert to a single PCM file in ffmpeg so it's doing the decoding then use eac3to to split it. Then I can compare to the original eac3to decoded output and see if the files are identical or not.


OK so...

1. Decoding the source .dtshd to FLAC using both eac3to and ffmpeg produces bit-identical files, although to be fair I didn't do that before - I split to WAVs in eac3to directly. Wonder if that's causing an issue for some reason, don't know why it would though.

2. Since the FLAC contents were verified against ffmpeg I split *that* to WAVs and compared those with my original WAVs. Again, they're bit-identical.

That pretty much confirms as far as I can tell that eac3to is decoding properly (or at least, identically to ffmpeg), which leaves Audacity and the actual DTS-HD MA encoder itself as possible culprits. The encoder theoretically shouldn't be the issue, but then theoretically, neither should Audacity; all I did in Audacity was import the 24-bit PCM files which turns them into 32-bit floats, added silence to either end, then exported back to 24-bit signed PCM again. Then I encoded them in the DTS suite as lossless DTS-HD MA with full 1509 kbps cores. Does any part of that sound iffy? The waveforms have pretty bad clipping in places, especially the centre channel, but I assume this is intentional compression for volume/dialogue clarity; this track is much louder than the 5.1 ones that were released elsewhere in the world but the waveforms for both are very similar, both have the clipping. I briefly thought it might have been that eac3to had erroneously truncated the dynamic range by misinterpreting something but it doesn't seem so.

Tried to verify Audacity output as well by importing a source WAV (Centre channel) into Audacity again then exporting it back to 24-bit PCM again to see if the files were any different (without adding or removing anything in the bitstream); nope, they're bit-identical.

To see if maybe the encoder itself was doing something different to the original encode, I encoded the source files (without my bitstream edits) back to .dtshd directly, and sure enough, the resulting file is indeed smaller than source. So maybe the encoder is discarding data, right? Well, no, it isn't: I tested this by converting the new .dtshd back to FLAC again and turns out it's identical to both FLAC files I made from the source .dtshd. So despite being set to the full settings, I think something is different about the way the encoder is creating its DTS core compared with the original source file. Maybe the mixdown is different? I wouldn't have thought so because I checked the mixdown tab and it's putting all the audio into the 5.1 mixdown for the core (I thought maybe it was discarding 2 of the 4 surround channels but it has been mixing both Lss and Lsr to Ls, and Rss and Rsr to Rs, so that's not it either). This brings me back to the .dtspbr thing: is it possible that when authoring a disc and incorporating the .dtspbr into the output, the size of the .dtshd stream is increased? This wouldn't necessarily surprise me; it seems like the point of the PBR (Peak BitRate) thing is to "smooth" the .dtshd audio stream so that the bitrate fluctuates less abruptly during playback (I don't know why this would matter but I guess it must). Presumably, if the bitrate fluctuations are reduced, this must necessitate higher bitrate than necessary during the fluctuations, which would put the filesize up.

Here's what the documentation says about PBR analysis:

The Peak Bit Rate Analysis Tool analyses variable bit rate encodings (DTS-HD Master Audio encoded streams) graphically plotting the selected encoding’s bit rate over time, as if the encoding had been “smoothed” for authoring using a Peak Bit Rate scheduling utility. The smoothing process redistributes data throughout the encoded stream for a more constant flow of data during disc played back. Smoothing is performed during the authoring process of a disc.

[resolution]

I have a data point for this topic. I just did a remux where I needed to add 17,977 ms of delay to an AC3 audio track from another source.

I tested the new MKV on my Oppo UDP-203. The Oppo definitely had some issues when this audio track was selected. Sometimes, it would smoothly play the beginning 17.977 seconds of video without a problem. Other times it behaved erratically: the video would visually glitch a little (as if the video stream was corrupt), or freeze entirely and lurch forward to the point when the audio kicked in. Never exactly the same error, at the same time, but some kind of problem was likely each time.

If I tried to do fancy things within that delay period (like freeze frame, frame advance, reverse and fast forward) it basically always choked in some way.

This MKV also retained other unaltered audio tracks with no delay, and if any of them were the actively selected audio, none of these issues occurred.

So, at least for this particular hardware player, using MKVs, a long-ish difference between video and audio length should probably be avoided if possible.

Trying another method, I used eac3to to pad the beginning of the AC3 file with 17,984 ms (or 562 AC3 frames) of silence. The Oppo likes this much better. From now on I will only use padding or trimming, not delays, to be safe.

[resolution]

Can anyone confirm if LPCM tracks have the equivalent of a "frame length" on Blu-ray? I've observed that tsMuxeR seems to round LPCM tracks down to 5ms multiples.

(Side note: From looking at a handful of Blu-rays recently, it seems audio tracks usually last slightly longer than the video. I wonder if that is the standard or best practice.)

[pipefan413]

Can anyone confirm if LPCM tracks have the equivalent of a "frame length" on Blu-ray? I've observed that tsMuxeR seems to round LPCM tracks down to 5ms multiples.

(Side note: From looking at a handful of Blu-rays recently, it seems audio tracks usually last slightly longer than the video. I wonder if that is the standard or best practice.)

Every one I've checked has been the opposite, audio shorter but by less than the duration of a video frame.

As far as I know there's no such thing as a concept of "frames" for PCM whether on BD or not, the stream can be whatever length you want and work fine. With PCM I usually make it precisely the video length, anything with frames I round down to nearest one. But honestly, I don't think it really matters.

The 5 ms rounding is interesting though. I'd say see if eac3to does the same thing or not!