I'm not talking about editing the raw capture, I'm referring to the parsed DTS. I understand the difference between PCM silence and DTS encoded silence.

I don't know if I mentioned it here before but my CLD-D925 knows it's playing DTS (a little logo pops up in the front display), a wav capture of DTS from this player will play as DTS in VLC. Once I parse it it requires the hex edit before it will play in VLC again

(2020-12-14, 02:29 PM)spoRv Wrote: FYI: PCM on laserdisc should (may) be 44056Hz...

Yes, but isn't that identical to CD sample rate? Which is still generally referred to as "44.1" kHz for simplicity?

Are you just saying this because I wrote it on the spreadsheet as "41000"? I can update the spreadsheet if that's what you're getting at but it didn't occur to me that that was important to point out at the time, hahah. EDIT: Actually, hang on, I'm not sure that's correct. A cursory glance at Wikipedia suggests that 44056 was never actually utilised, only proposed based on NTSC numbers. Looks like they ended up using 441000 Hz in which case I wasn't even simplifying, just stating the actual number, hah. https://en.wikipedia.org/wiki/44,100_Hz

(2020-12-14, 02:32 PM)zoidberg Wrote: I'm not talking about editing the raw capture, I'm referring to the parsed DTS. I understand the difference between PCM silence and DTS encoded silence.

Cool, so when you said you'd lopped stuff off the end, how did you do that editing? In a hex editor or a DAW? If done in a DAW, you're probably just creating another partial frame in a different place, I'd guess. But certainly every time I tried chopping off a whole frame, the decoding error did not appear. Didn't matter if I chopped off the last frame or the last 10, still decoded fine with no error. (And I hope I didn't seem like I was condescending, I thought maybe you'd misunderstood because I hadn't communicated the distinction clearly enough!)

(2020-12-14, 02:32 PM)zoidberg Wrote: I don't know if I mentioned it here before but my CLD-D925 knows it's playing DTS (a little logo pops up in the front display), a wav capture of DTS from this player will play as DTS in VLC. Once I parse it it requires the hex edit before it will play in VLC again

One thing that I didn't mention is that I seem to having weird issues with VLC and audio lately. This also apparently includes it refusing to play back captured 44.1 kHz LD DTS at all, it just does the "white noise" thing as if it wasn't valid. Both for the .wav and the parsed DTS (even after fixing headers). MPC on the other hand has no such issue and plays it absolutely fine.

The 'lopping off' I was referring to was in eac3to using the edit function. I write up an edit list in audacity then use eac3to to edit the DTS to avoid transcoding. Using the edit function in eac3to works to the nearest frame so I guess the final partial frame is ignored and as such remains after the edit is complete.
Strange about VLC not recognising the finished DTS file, I think I had this problem once but can't remember how I fixed it. I may have just reparsed/hexed the capture again

(2020-12-14, 03:49 PM)zoidberg Wrote: The 'lopping off' I was referring to was in eac3to using the edit function. I write up an edit list in audacity then use eac3to to edit the DTS to avoid transcoding. Using the edit function in eac3to works to the nearest frame so I guess the final partial frame is ignored and as such remains after the edit is complete.
Strange about VLC not recognising the finished DTS file, I think I had this problem once but can't remember how I fixed it. I may have just reparsed/hexed the capture again

Ah right I'm with you. That could very well be because if you're cutting the end of it off, it won't even be reading the partial frame and therefore won't conk out: it's just going to read the file up to the edit point then crop the remaining data off, so there would be no need for it to read past that point to see the dodgy frame and crap its pants, hence no error.

Incidentally, if you have an *actually* incomplete DTS frame (as in, literally not enough bytes to fill the frame) then eac3to will skip it. So say rather than pasting in the end of the data required to finish the frame, you just delete a chunk of the bytes, meaning the header tells the decoder that the frame contains 3584 bytes but there are only actually 3000 (or whatever) bytes left in the file; in that case, eac3to just reads until it runs out of data, realises the last frame is incomplete, and skips it. The cause of the error is that DTS Parser pulls zero bytes from after the bitstream stopped coming from the player, and assumes they're supposed to be part of the last frame since the last frame has to be 3584 bytes... but those zero bytes are not sufficient to close the frame, so the decoder tries to read it as a valid frame (because it sees that it does actually contain 3584 bytes) and fails when it finds those bytes not to actually form a valid frame.

The VLC thing is annoying me and has me worried there may be something up with the capture but every capture I've done plays in MPC and not VLC so it could be a VLC-specific problem rather than a bitstream problem. Hmm.

(2020-12-14, 02:49 PM)pipefan413 Wrote:

(2020-12-14, 02:29 PM)spoRv Wrote: FYI: PCM on laserdisc should (may) be 44056Hz...

I'm not sure that's correct. A cursory glance at Wikipedia suggests that 44056 was never actually utilised, only proposed based on NTSC numbers. Looks like they ended up using 441000 Hz. https://en.wikipedia.org/wiki/44,100_Hz

To further clarify, I could've sworn I remembered reading about this a while back and I just found it:

(2019-04-19, 03:09 AM)schorman Wrote: I can weigh in on the dabate about 44,056Hz.  It is most definitely misinformation and can easily be proven false by reading through the documentation of happycube's ld-decode project. 

My quote from another forum at redacted.ch:

"My point is that that info is completely bunk. There is not one disc that was ever authored that way. PAL and NTSC discs with digital audio all have stereo PCM (or DTS encoded as PCM) tracks, sampled at 44.1kHz-16bit. This 44,056 version has never been documented to exist. Wikipedia is wrong on this.

In fact, using the software LD decoder here: https://github.com/happycube/ld-decode, by happycube, the same code can be used to decode to digital audio from the raw RF signal produced by reading either an NTSC LD or a CD. In short, NTSC laser discs store the audio track in an identical way to a CD. They do not use a 44,056Hz sampling rate.

My guess is that this info is based on the original LD standards published in the 70's. PCM was typically stored on video cassettes in those days, and was recorded in a way that relied on compatibility with a black and white NTSC or PAL video system. This was before the advent of the CD, and before Sony and Philips settled on the sampling rate they would use.
Remember that while LDs predate the CD, they did not utilize digital audio until after the Redbook standard was in place, and CDs were on the market. It stands to reason that any earlier plans on how to store digital audio on LD may have been altered to match the already prevalent 44.1kHz technology. "


Further quote from HappyCube at OT.com:

https://originaltrilogy.com/topic/Unoffi...e/1#791682


Based on available knowledge, the modulated RF signal used to store the Digital Audio track of a LaserDisc is identical to that used by CDDA.  They are both storing audio as 44.1kHz at 16 Bit, and can both be decoded/demodulated in the exact same manner using the same electronic circuitry or software decoder, as is done by ld-decode.

So yeah, seems LD audio is not 44056 Hz but 44100 Hz. The 44056 Hz thing may just have been something that occurred early in the standard's development and was never actually used, from what I found from a quick look about.

That seems to be an odd myth which I also saw stated here and there, but in fact, it is 44100 Hz.

Okay, others were already faster. To add something original then as a side note: some LaserDiscs in fact also use preemphasis for PCM tracks, just like early CDs.

(2020-12-14, 04:26 PM)pipefan413 Wrote: So yeah, seems LD audio is not 44056 Hz but 44100 Hz. The 44056 Hz thing may just have been something that occurred early in the standard's development and was never actually used, from what I found from a quick look about.

Now, last time I captured a laserdisc was many months (few years?) ago, hence my memory could not serve me well (also age does not help), still I'm (99.99%) sure that, capturing with VirtualDub, it displayed 44056Hz - that is 44100*1000/1001 (rounded) - for NTSC discs, using a bit-perfect capture card via digital input.

(2020-12-14, 05:09 PM)little-endian Wrote: To add something original then as a side note: some LaserDiscs in fact also use preemphasis for PCM tracks, just like early CDs.

Correct! And it's a bit of a pain in the hole. But SoX deemph seems to work well, in my opinion. I've not yet pinned down the exact moment in time that it seems to switch, but it appears to be somewhere between 1987 and 1988, or thereabouts.

To further complicate matters, it appears that on at least some LDs, the analogue track might have been created from a digital 44.1 kHz master that still had pre-emph on it, in which case you might end up with the rather silly situation of needing to de-emphasise an analogue track to get the frequency response closer to what it should be. And I'm not even referring to LDs with analogue + PCM; the one I'm thinking of is analogue only, but was released around the time things were beginning to switch over to digital. But that's hopefully an edge case.

(2020-12-14, 05:25 PM)spoRv Wrote:

(2020-12-14, 04:26 PM)pipefan413 Wrote: So yeah, seems LD audio is not 44056 Hz but 44100 Hz. The 44056 Hz thing may just have been something that occurred early in the standard's development and was never actually used, from what I found from a quick look about.

Now, last time I captured a laserdisc was many months (few years?) ago, hence my memory could not serve me well (also age does not help), still I'm (99.99%) sure that, capturing with VirtualDub, it displayed 44056Hz - that is 44100*1000/1001 (rounded) - for NTSC discs, using a bit-perfect capture card via digital input.

You could very well be right because I'm just regurgitating info I've seen online, I haven't really attempted any kind of verification of this personally. But yeah, it seemed the consensus was that LD audio is identical to CD sample rate of 44100 Hz rather than the more NTSC-friendly 44056 Hz.

That being said, I routinely align LD PCM (bit perfect) audio captures with analogue audio captures from LD, with the analogue being resampled to 44.1 kHz for alignment. And in not one single case thus far have I seen them go significantly out of alignment over the course of a given track. If the PCM was supposed to be played back at 44056 Hz, then it would drift quite a bit by the end (several milliseconds). I think at most I've seen a drift of about 3 ms or something, which might not be enough to suggest that the digital track was running 44 samples per second faster than the analogue version.

Actually it should drift 3.6s every hour!

Yet, I guess that, even if it's 44056Hz, it does not drift as it's in sync with 23.976/29.970fps, and it's just "rounded" to 44.1Khz by most software, even if it's not - again, "IF"!

(2020-12-14, 05:51 PM)spoRv Wrote: Actually it should drift 3.6s every hour!

Aye right enough:

60 * 60 * 44056 = 158,601,600‬ samples per hour
60 * 60 * 44100 = 158,760,000‬ samples per hour

So you'd be playing 158,400‬ extra samples per hour, which is...

60 * 60 * 44 / 44100 = 3.59 seconds

Which pretty much debunks the whole 44056 Hz idea, imo.

(2020-12-14, 05:51 PM)spoRv Wrote: Yet, I guess that, even if it's 44056Hz, it does not drift as it's in sync with 23.976/29.970fps, and it's just "rounded" to 44.1Khz by most software, even if it's not - again, "IF"!

But if it was captured then rounded up, it would be out of sync when aligned with an analogue capture which has been resampled to precisely 44100 Hz. Which is what I do with literally every PCM LD I capture. And none of them have drifted anywhere near that much.

To be clear, I'm not talking about it going out of sync during playback, I mean literally lining up sample-for-sample in a DAW (e.g. Audacity). They don't drift by > 3 seconds per hour.