-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audio offset for AC3 #844
Comments
Absolutely yes. Saves a lot of time in post-processing and what's even more important: It would be less error prune. A lot of people using DDD to preserve movies will miss the necessary delay. |
I think you'ld have to add silence to the ac3 file itself. I originally thought it'd be very tricky, but some googling found https://superuser.com/questions/579008/add-1-second-of-silence-to-audio-through-ffmpeg . |
Yes, if you have an AC3 frame with silence with the same bitrate, you can just copy it at the beginning. But you can only correct multiples of 32ms, cause that's the duration of one AC3 frame (with 48khz sampling rate). |
I also noticed this, I've been using |
There is another issue here. Due to the way lossy codecs work, and AC3 is no exception, there should be a priming of silence in the start, not present in the original source audio on disk creation: 256 samples in the very start and some in the end (end remainder can be absent). Those should be cut. But check in audacity whether AC3 has silence in the start. Mp4 has edit list for that, mp4 has edts atom with media time 256. So it is not just 190 ms. |
Having watched a few discs with AC3 audio now, it works really well, but lip sync is consistently out with the AC3 track - it needs to be delayed by about 190-200 ms to line up with the EFM and analogue tracks.
The PAL/NTSC LaserVision specs note that EFM decoding will incur a delay, and say that you should advance the EFM audio by 15.3 ms relative to the analogue audio to compensate. So I suspect the LaserDisc AC3 spec (which we don't have) has some similar wording.
Would it be worth having ld-decode take this into account when feeding RF to the AC3 demodulator?
The text was updated successfully, but these errors were encountered: