Laserdisc PCM Capture Guide

[pipefan413]

This is all arguably a bit off-topic for this thread but this is where the discussion arose around LD DTS that led to my breakdown of it, so I'm putting this here for now; mods/admins, feel free to move it somewhere else if you want, or I can potentially start a separate thread specifically for this stuff and put all the info from these posts in there. That might not be a terrible idea actually. Anyway, out with it...

DTS codec structure (frames, blocks, and samples)

DTS sorts its audio samples into "frames", which are further organised into "blocks" of a set number of audio samples. For 48 kHz audio (e.g. DVD/BD), each normal frame contains 16 blocks, each containing 32 audio samples (which is why a DTS frame from DVD or Blu-ray contains 512 samples: 16 blocks x 32 samples = 512). For LaserDisc, which has its digital audio output set at 44.1 kHz, each frame contains 32 blocks of 32 samples (32 x 32 = 1024 samples per frame).

The headers written by DTS Parser look like this:

7F FE 80 01 FC 7C E0 02 63 A0 0D 3A 80 09

... but they should look like this:

7F FE 80 01 FC 7C DF F2 62 C0 0D 3A 80 09

You can fix that in a few seconds with a simple replace all operation. But what is that actually doing? And is part of it possibly relevant to what's causing decoding problems with the DTS Parser output? (Spoiler: yes.)

To understand what's going on in the hex code it needs broken down to the binary level. Only 5 bytes are relevant here, so I'll only cover those ones:

7C = 01111100
E0 = 11100000
02 = 00000010
63 = 01100011
A0 = 10100000

... needs to be changed to

7C = 01111100 (unchanged)
DF = 11011111
F2 = 11110010
62 = 01100010
C0 = 11000000

These 5 bytes contain the following metadata, most - but not all - of which appears to be parsed correctly by DTS Parser:

ftype:
Frame type, being normal ("1") or termination ("0").

short:
The number of samples by which the termination frame falls short of the normal length of 32 samples; for normal (non-termination) frames, the value is 31 (counting from 0 as digital systems do, that's 32).

cpf:
CRC flag indicator (if there is a CRC present in the header, the value will be "1"; for LaserDiscs, it's "0").

nblks:
Number of blocks (of samples) per frame. For 48 kHz DTS from DVD, it's 16 blocks of 32 samples, so nblks = 15 (again, counting from 0, that's 16). For 44.1 kHz DTS from LaserDisc, it's 32 blocks of 32 samples (32*32 = 1024 samples per frame), so nblks = 31.

fsize:
Number of bytes per frame (frame size). For a 48 kHz 1536 kbps stream, this would be 2013 bytes, represented as "00011111011100" in binary (2012 in decimal, or 7DC in hex), but since LaserDiscs contain 44.1 kHz 1235 kbps streams instead, it should be "00110111111111" (3583 in dec, DFF in hex) because each frame is 3584 bytes long.

amode:
Audio channel arrangement. For all DTS LaserDiscs this is the classic 5.1 layout, but note that the LFE channel is not counted here because of how the codec derives it from the file. L+C+R+Ls+Rs is represented by the decimal value "09", which in binary is "001001".

sfreq:
Sample frequency. For LaserDiscs this is always 44.1 kHz, represented by the DTS codec by the dec/hex value "8" which is "1000" in binary (for 48 kHz from DVD/BD it's the hex value "D" which is "1101" in binary).

rate:
Bitrate, which for LaserDiscs is always 1234 kbps, represented by the decimal value "22" which in binary is "10110". For some reason I haven't yet had time to investigate,  DTS parser thinks it's 11101 (29), which is partly why if you try to play back a raw capture straight out of DTS parser it's all garbled and sped up.

mix / dynf / timef / auxf / hdcd:
These are all 1-bit flags that I think I've talked a bit about before when I was researching the header for picking apart DTS-HD specifically, but the main thing here is that they're all 0 for LaserDiscs and therefore can be left alone.

I just discovered something interesting while testing eac3to's behaviour with LaserDisc DTS files. I wanted to test whether it would correctly write all the headers, basically, if I did something simple like applying a delay to a .dts file recorded from a LaserDisc as PCM-stored DTS and correctly parsed to a .dts container. Turns out it doesn't *quite* manage it! This has to do with the bytes that lie after the part I broke down in the section quoted above, because these later bytes weren't relevant to the topics I was discussing before. This new discovery makes them relevant though.

Control: I took the .dts file containing a parsed DTS stream for side 1 of TOY STORY and removed the first 13 DTS frames in a hex editor (by just searching for the start of the header and deleting everything before the 14th instance of that string of bytes).

Test: I took the same .dts file and applied a negative delay in eac3to (-301ms*) to remove the same 13 frames

*because...

LaserDisc DTS has...
44100 samples per second, arranged in frames made up of
32 blocks of 32 samples, amounting to
32 x 32 = 1024 samples per DTS frame

Based on my AviSynth script, to align side 1's audio to its video, I had to remove 18 frames at 60/1.001 fps, which at 44.1 kHz would be equivalent to...
18 / (60/1.001) * 44100 = 13,243.23 samples
13243 / 1024 = 12.93 DTS frames (so closest edit is 13 frames)
13 * 1024 = 13312 samples
13312 / 44100 * 1000 = 302 ms

Applying the delay as -302ms in eac3to results in it reporting that it couldn't fix an additional delay of 1 ms, so it's calling it 301 ms even though it actually does chop off 13 DTS frames (I checked in a hex editor obviously). 301 ms at 44100 Hz is 0.301 * 44100 = ~13,274 samples, and 13,274 / 1024 = 12.96 DTS frames (so it rounds to 13 as I want it to here), but equally, 302 ms at 44100 Hz is 0.302 * 44100 = ~13,318 samples, and 13,318 / 1024 = 13.006 DTS frames. But y'know, whatever, it gets the actual edit right in practice in the sense that it cuts off the right number of frames.

The eac3to file is slightly wrong because eac3to writes the 12th byte of every header as 3B instead of 3A, but leaves the 13th byte untouched. In binary that breaks down as...



vs



I linked this in the full version of the above quoted post but here's my full breakdown of the frame header (consolidating info from other sources e.g. 🔍https://wiki.multimedia.cx/index.php/DTS and 🔍http://www.stnsoft.com/DVD/dtshdr.html): 🔍https://docs.google.com/spreadsheets/d/1...v1WPO1MrQ/

Since I can't find much info on these flags, I looked at some other DTS files I had lying around from other sources. The part of the 12th byte (byte 11, counting from zero) that's being changed by eac3to pertains specifically to "pcmr", the source PCM resolution, which I suspected might be the same thing or at the very least related to bit depth. This does indeed appear to be the case, and I suspect I might have an idea why it's being altered by eac3to!

In DTS files made from 16-bit PCM, pcmr = 000 (bin); bytes 11-12 are 3A 00
In LaserDisc DTS files, which are 20-bit according to DTS Parser and MediaInfo, pcmr = 010 (bin); bytes 11-12 are 3A 80
In DTS files made from 24-bit PCM, pcmr = 110 (bin); bytes 11-12 are 3B 80

So why do I suspect eac3to is changing it?

The analogue audio my capture card records is 20-bit, but it's padded up to 24-bit for storage; the real bit-depth is 20-bit, but the additional 4 bits of depth is just empty data (zeroes) so the actual "PCM resolution" in this case might be thought of as 20-bit rather than 24-bit even though it's stored in the .avi (or .wav, or .flac) container as if it's 24-bit. Why does it get padded to 24-bit? It would seem because storing digital PCM audio as 20-bit just isn't really a thing, so it has to be padded up to 24-bit to be correctly understood by the various software and hardware that need to be able to read the data. And unless I'm mistaken, 20-bit audio is very much a legacy thing: the only reason my capture card uses it is that 20-bit audio was the broadcast SMPTE standard in the standard def days, which is also when LaserDiscs were in the wild. I've not done any real research into this specifically but I'm guessing audio was generally 16-bit, then an extra 4 bits of depth were used to allow greater dynamic range, then somewhere along this was increased by a further 4 bits to get to the current generally accepted maximum required depth of 24-bit (with 32-bit float for DAWs etc. being essentially equivalent to 24-bit fixed integer depth but with floating headroom for you to work with until you're done and ready to dither to fixed point at the end).

My suspicion is that eac3to doesn't really bother checking / accounting for 20-bit audio in certain circumstances because it's so uncommon. If you feed it a 24-bit PCM bitstream where the actual samples in it only use 20 bits of depth, it will recognise this and report "The original audio track has a constant bit depth of 20 bits." But feeding it 20-bit DTS files from LaserDisc and asking it to apply a delay is different, because they're encoded as DTS rather than being uncompressed PCM and it isn't actually decoding it so it doesn't test what the actual bit depth is, it presumably just checks if it's 16-bit or greater than 16-bit. If greater than 16-bit, it appears to assume that it must instead by 24-bit because you don't get 20-bit DTS files on DVD or Blu-ray, so it writes PCM resolution as 24-bit (coded binary value 110), but that's actually incorrect for these 20-bit files.

So if anybody out there is applying delays to LaserDisc DTS files with eac3to, you might want to go in and fix the headers afterwards by replacing the "3B" eac3to writes to the headers with "3A" again!

Alternatively, you can do what I tend to prefer myself and just delete the headers in a hex editor so you don't have to bother using eac3to at all (you'll be hex editing anyway if you fix it, so it seems like the faster way to me).