No no, I mean that sampling rate is maintained at 44056Hz but the software display it as 44100Hz - but at least VirtualDub capture did display at 44056Hz...
May you try a capture "on the fly" using VirtualDub and a digital input, and check the sampling rate displayed? I'd make it myself if only I could too curious to know!
(2020-12-14, 06:03 PM)spoRv Wrote: No no, I mean that sampling rate is maintained at 44056Hz but the software display it as 44100Hz - but at least VirtualDub capture did display at 44056Hz...
May you try a capture "on the fly" using VirtualDub and a digital input, and check the sampling rate displayed? I'd make it myself if only I could too curious to know!
I understand, but that would mean that CD audio is also actually 44056 Hz, given that the data stored on the LD is identical to CD format. And I'm almost certain it's not.
Software like RX (which I do the resampling in) and Audacity (which is mostly what I use for alignment) don't know if the audio is off a LaserDisc or a CD or what, they just render it out as it is. If I fed 44056 Hz audio to Audacity as 44100 Hz, then the samples would be displayed as "sped up" (too frequent) and this would put it out of alignment with my 100%-definitely-44100 Hz resampled analogue capture (recorded at 48000 Hz, resampled to 44100 Hz in RX - *not* 44056 Hz). But it doesn't. They line up very very precisely, in many cases I've seen thus far they've actually remained accurate *to the individual sample* from start to finish once the starts are lined up. If the correct sample rate for the PCM was actually 44056 Hz, then rendering it as 44100 Hz would mean the digital track would get significantly ahead of the analogue one. It doesn't.
I've never attempted a capture in VirtualDub, I just use it for monitoring/resyncing stuff after capture, so I'm probably not the best person to check that specifically.
(2020-12-14, 05:59 PM)pipefan413 Wrote: Which pretty much debunks the whole 44056 Hz idea, imo.
Yeah, also if PCM would be at 44056 Hz, so would be DTS. Either way, one should be able to derive the correct sample rate and debunk any myth by checking the amount of recorded samples over a given (longer) time as any S/PDIF receiver will have to synchronise to that rate, no matter what the actual set sample rate in the editor is (the specific behaviour is also driver-dependent though). For example, with the Terratec Xfire 8.0 HD, if set to 192 kHz in the editor but fed with only 44.1 kHz, one second will just last "longer", but the end result will be the same as long as one saves the file with the correct sample rate flags.
2020-12-15, 07:45 AM (This post was last modified: 2020-12-15, 07:52 AM by schorman.)
(2020-12-14, 02:29 PM)spoRv Wrote: FYI: PCM on laserdisc should (may) be 44056Hz...
NO! NO! NO! Laserdisc audio is NOT, and never has been 44056 Hz. This rumor needs to die. It is absolutely not true. The only reason this seems to persist is a poorly quoted wikipedia article.
2021-01-02, 04:41 AM (This post was last modified: 2021-01-02, 05:13 AM by 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 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:
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...
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).
2021-01-02, 04:48 PM (This post was last modified: 2021-01-02, 04:52 PM by pipefan413.)
(2021-01-02, 04:46 PM)zoidberg Wrote: In the real world, what are the implications of this altered byte, can it affect playback?
As far as I can tell every DTS LD I've captured, parsed and edited in eac3to (admittedly only 2 so far) decodes just fine
Well, maybe not, I don't know. But as I said, it pertains to bit depth, so it might matter. If I'm correct then it basically means that the bitstream will be interpreted as 24-bit instead of 20-bit without actually changing the data so it *is* 24-bit, so that seems to me like it'd be an issue. Harmonic distortion possibly? Incorrect gain? Was testing late at night so didn't check on speakers.
But like I said, easy to fix. Just replace that one byte in the headers, that's it.
(2021-01-02, 05:03 PM)zoidberg Wrote: The 20bit-depth 'resolution' of DTS LD was always an equivalence as compared to 16bit PCM
OK, that would not surprise me at all, but as I described above, it's not being written with the 16-bit value but the 24-bit value instead. Even if it was the 16-bit one, I'd be concerned about values being truncated or clipped. But it's not that, it's making the header declare the audio as 24-bit instead of 20-bit. That'd possibly be fine if it somehow gets packed with zeroes on playback, which I suppose theoretically it might do, but I'd be surprised given that the header is explicitly saying "decode these as 24-bit samples" but they're actually 20-bit.
Up to you and might be a non-issue if nobody's noticing any audible problem but if it were me I'd just run a Replace All on the headers, if all your eac3to edits were just trims (cutting but not doing anything to bit depth). Although I'm assuming you might not have kept the files as DTS, since it might make sense to decode to a different container before use. So the test would be easy: fix that byte in the .dts, decode again, see if the files are identical or not!
2024-07-25, 08:05 PM (This post was last modified: 2024-07-25, 08:10 PM by borisanddoris.)
For anyone out there still capturing AC3, which demodulator are you using? I recently switched from using a Sony to a Yamaha, and I'm finding that while my receiver used for monitoring locks on instantly and no audio is missed, when doing a recording, it doesn't always lock on instantly. Using the same SPDIF input for LPCM and DTS yield zero issues with locking onto the signal.
I am finding by skipping backwards until Quicktime 7 locks on will work it's just not something I ever had to do with the Sony. Any thoughts on what might be causing a delay in a lock for 16-bit 48khz only? I even tried plugging the demodulator directly into the Mac and skipping the receiver but the anomaly is the same.
Shoot, with the Sony, I used to be able to cap AC3 discs with a side change and still hold a lock on the signal. It was pretty amazing.
too curious to know!
![[Image: dts-3-Avs3-B.png]](https://i.postimg.cc/gJ5bntXD/dts-3-Avs3-B.png)
![[Image: dts-3B.png]](https://i.postimg.cc/XqV1Nwx8/dts-3B.png)
