Posts: 141
Threads: 16
Joined: 2019 Jun
Thanks: 21
Given 87 thank(s) in 53 post(s)
Country:
Hey everyone!
Trying to capture AC-3 sound from an LD and having some issues.
Here is what I'm doing:
*Capture AC-3 through my RF-demod into Reaper (48/16 WAV)
*Taking that file and running it through BeSplit to make an AC-3 file. This sounds great in Foobar. No problems whatsoever
My friend is taking these AC-3 files and running them through UseEAC3to in order to create w64 files. At this point, they are getting a warning that says "the track is not clean".
Should I be concerned about the "track is not clean"? Is that just a warning to ignore? Again, the file sounds perfect when the AC3 file is playing on Foobar. Any attempt at processing through EAC3to messes it up though.
Any help would be great! Thanks!
Posts: 2,050
Threads: 56
Joined: 2016 Dec
Thanks: 161
Given 1009 thank(s) in 613 post(s)
Sounds like some of the file is corrupted, AC-3 works in 32ms frames so it's possible some of the frames were damaged/altered during capture. You didn't edit the ddwav file in any way before running through besplit by any chance?
Posts: 141
Threads: 16
Joined: 2019 Jun
Thanks: 21
Given 87 thank(s) in 53 post(s)
Country:
After lots of trial and error, I was able to use DelayCut to produce a file that isn't unclean according to UsEac3To!
I added the AC-3 capture track into DelayCut and did tests with each form otf "CRC error". "Fix" ended up producing AC-3 tracks that when fed into UsEac3To there was no "unclean warning". I also noticed that it seemed to also chop off moments of silence (shortening the side break changeover, cutting out a lot of the silence before the film during the FBI warnings and whatnot). Hopefully that is normal.
Should I be concerned about "fix" cutting time off the recoding?
Posts: 1,554
Threads: 60
Joined: 2015 Jan
Thanks: 229
Given 627 thank(s) in 372 post(s)
Country:
Given that the sections that were removed are (a) located at the beginning of the film and at the side-change (b) silent, I wouldn't be concerned. (I guess that you plan to resync the track anyway.) If you were losing frames in the middle, that would be different. Ideally, of course, you'd want to capture a file that didn't read as dirty, but I don't have much experience with capturing AC-3, so I can't help you much there.
Posts: 2,050
Threads: 56
Joined: 2016 Dec
Thanks: 161
Given 1009 thank(s) in 613 post(s)
If you open up an AC-3 file as captured from the demodulator (ie a 16bit, 48kHz wav file) in any DAE and zoom right in on the timeline you'll see the individual 'frames' which are actually small packets of data surrounded by pure silence, with the duration from the start of one packet to the start of the next packet being exactly 32ms (the length of an AC-3 frame). This is how AC-3 is padded within a 48kHz bitstream for delivery to A/V receivers and the gaps are why it sounds so awful played back as standard PCM as opposed to DTS which sounds more like white/pink noise.
My guess is that during the preparation of the ddwav for processing by besplit some of these frames got clipped which is what eac3to is objecting to, it expects to see the frames intact. AFAICT besplit isn't bothered by the damaged frames and processes them regardless. So long as the disc isn't rotted/damaged you shouldn't get bad frames mid-playback so long as the demodulator maintains a lock on the RF signal.
The easiest way to avoid this is to neatly trim the initial capture so it only contains complete AC-3 frames, whilst you're doing this you can splice the different sides together into one complete file for processing with besplit. When the resulting AC-3 file is reviewed there will still be pure silence at side breaks because even silence has to be encoded in AC-3, but this can be removed when editing for sync etc. This editing can be done in any DAE that doesn't mangle the bits by resampling or dithering, I just use Audacity set to 16/48.
