@Chewtobacca Well, gee, sorry. I sometimes tend to "think aloud" and write a bit more than necessary.

You wrote at some point that 44056 Hz was the actual sample rate of Laserdiscs, and I found the thought really strange, because 44056 is just a rounded number and would, over the course of 2 hours movie, produce about 10ms of drift in itself. Not terrible I guess, but certainly an avoidable source of imprecision. And producing equipment that works precisely at 44055.944... sample rate, I don't know, doesn't seem right to me, it would make everything difficult, but ofc I could be wrong. Plus, every professional audio software I ever used won't let you set the sample rate past the comma, only as integers (round numbers).

@OP
What kind of capture do you have of the LD? Is it a bit-perfect capture or simply a capture of the Laserdisc player's output at 44100? If it's bit-perfect, I'm gonna argue that whatever recording software you used simply adapted itself to the speed the data came in, and thus you ended up with 44.1 kHz audio (because that's what the stream itself is coded as) even though it may have played slower on the Laserdisc player.

To verify this theory, you could do an analogue capture of the audio from the laserdisc player and see if it syncs better, which would be the case if the native 44.1 kHz audio is played back at ~44,056 Hz. You would then possibly also be able to see a bit of a frequency cutoff on the spectrum of the audio file.

If an analogue capture will result in the same drift and the spectrum looks normal, that theory is at least disproven and it will indicate that the laserdisc is indeed played at 44100. Of course that still wouldn't tell us whether the frame rate of the laser disc is 60 or 59.94.

Here's a tidbit of information I found on the Laserdisc wiki page that might be of interest: https://en.wikipedia.org/wiki/LaserDisc#Design
Look at the part called CAV, which appears to be the initial Laserdisc design. There it says

Quote: CAV discs were spun at a constant rotational speed (1800 rpm for 525 line and 1500 rpm for 625 line discs)[20] during playback, with one video frame read per revolution. In this mode, 54,000 individual frames (30 minutes of audio/video for NTSC, 36 minutes for PAL) could be stored on a single side of a CAV disc.

So, 1 frame per revolution. 1800 revolutions per minute for NTSC (525 lines). That's a round 30 revolutions per second. If it was 29.97 fps, we would expect the RPM number to be ~1798. Unless of course this number is incorrect and they rounded it up. And of course this also refers to the older Laserdisc standard that was eventually succeeded by others and didn't even have digital audio yet, so take it with a grain of salt I guess.

For another clue, I also went and checked on Dolby Digital (AC-3) to confirm my suspicion. Here's some details about the data format: https://en.wikipedia.org/wiki/Dolby_Digi...al_details

According to those, the sampling frequency is saved in the header as a 2-bit field with the following options: '11'=reserved '10'=32 kHz '01'=44.1 '00'=48

Since a bit can only be 1 or 0, this means that any other sampling frequency than 32, 44.1 or 48 is impossible. Of course PCM doesn't have such restrictions, but we do know from experience that bit-perfect PCM and AC-3 captures from Laserdisc do sync up and the AC-3 captures are typically 48kHz.

To go a bit further, AC-3 is saved in syncframes: http://www.stnsoft.com/DVD/ac3hdr.html
Laserdisc AC-3 is 384 kbps, according to that list that results in 768 16-bit words of actual audio information per syncframe at 48kHz. Which means 768*16 = 12288 bits. Divide 384 Kbps / 12288 bits and you get 31.25 Hz. Surprisingly clean number, but of course a bit too high. But this doesn't account for all the headers and error checking also included in a syncframe. If you add a speculative 64 bytes (8*64 bits) - a rather round number - for headers, you get 384 Kbps / ((16*768)+8*64) bits = exactly 30 Hz.

There is no whole number of bytes to add that will result in exactly 30*1000/1001 frames. Now, I know this is speculative, but this indicates to me that from an engineering standpoint, it would make sense to have the Laserdisc have 30 AC-3 syncframes aligned with 30 actual image frames. Or in the very least, have video and audio frames align once a second (in the case of PAL). For example film prints also have those little AC-3 QR-codes, I wouldn't be surprised if those were individual syncframes as well that can be individually decoded and line up perfectly with the film frames. Of course this doesn't have to be the case, but it would be ... elegant.

This would speak for the theory that the players simply play it back slower than the format is "natively" saved.

(2019-04-16, 04:56 PM)TomArrow Wrote: You wrote at some point that 44056 Hz was the actual sample rate of Laserdiscs, and I found the thought really strange, because 44056 is just a rounded number and would, over the course of 2 hours movie, produce about 10ms of drift in itself.

No, I didn't write that 44056Hz was an exact figure.  The debate online is about whether NTSC LDs are 44056Hz or 41000Hz.  On reflection, I think that bronan is probably right and that 44056Hz is misinformation, but I'd like to see a paper such as this one (which is behind a paywall); otherwise, all we have to go on are paraphrases or assertions from various people, and even those who really know their stuff can make mistakes or simplify complex issues.  Even precise details from papers don't always clarify things completely, because specifications are often messy compromises that leave some details unresolved.  The DVD spec is a prime example of this, and I suspect that the confusion over the sampling rate of NTSC LDs might result from another such example.

44056Hz equipment was undoubtedly produced.  I don't know the specifics of how it worked.

I believe this is the article from behind the paywall: https://www.academia.edu/23545832/Digita...ng_Formats

At quick glance I'm not finding references to the sampling rate but multiple places that mention an explicit compatibility with the Compact Disc format (which as we all know is 44.1kHz at 16 bit) as well as Compact Disc encoders and decoders:

Yeah, I've just found it here without the need for Google or Facebook sign-in.  It appears to be the same paper, in which case the reference on Wikipedia is puzzling.

Good find. I can imagine they have some sorts of rules on how to reference scientific articles, for example due to licensing issues but also to avoid linking a pdf that may go offline randomly, as tends to happen on the internet.

I agree. What's puzzling is that it's given as a reference for a claim that doesn't appear in the paper, at least not explicitly.

Yea, and the abstract even directly says: "We show the feasibility of a combined digital audio signal according to the Compact Disc Digital Audio format and the current analog audio signals in the NTSC video format, enabling the realization of a compatible system." Of course this is a research paper and not a spec, but yea, it doesn't seem like that paper has any information to make the Wiki citation valid.

Have you guys read it completely? I just skimmed for mentions of 44100 or 44056 or mentions of sampling rate, too lazy (and too incompetent) to read it all. It's possible there's some detail mentioned somewhere that implies a slower playback on NTSC discs without saying it explicitly.

BusterD, have you tried changing the sample rate by changing the headers as opposed to resampling (in other words, doing a pulldown)?

EDIT:  I've never had need to perform a pulldown, but ffmpeg seems to accomplish the task.


AviSynth's Info() function reads the result as 44056Hz.  MKVToolNix will mux the output, and upon playback of the resulting MKV, MPC-HC reads the audio as 44056Hz.

Pretty sure that's what he meant. Most audio editors allow you to reinterpret/change sample rate with a few clicks without needing to resample or anything. For example in Audition it's something like Edit->Interpret Sample Rate.. and in SoundForge you can simply double click the sample rate and set a new one. Nice to know how it works with ffmpeg tho.