How to fix broken audio?

[ding73ding]

I have a few vids (maybe 1-2% of my collection?) with a very specific audio problem. The audio is off for about one second every two seconds. I.e. one second on, one second off. Obviously it's very annoying... but not annoying enough to delete the video (since JAV is reasonably usable without sound on). Some of these are somewhat older titles that's impossible to find alternatives.

The symptom seem to suggest a decoding or encoding problem. But just today I got a file (RCTD-299) with has a 2 minutes (Chinese) ad inserted before the beginning. The ad itself has functional audio, but the entire 120 minutes of the film itself has the on/off problem. Since most files are encoded in one go, the problem shouldn't come from the decoding or encoding (at least the last time it's encoded).

Do you know why such problem appears? Better any suggestion to fix it?

I happen to have for this case an old SD version (which I've re-coded to h265) with a working audio track, so I'm half thinking about splicing the good audio from the SD version with the video stream from the FHD file. Anyway even if it works it's just this one case. Explanation and/or solution of the broken audio would be appreciated!

 

[intrepid8]

You can probably change the synchronization in your video player to fix it on the fly (and it might even save for future playback with some players with other preferences).

Maybe a repair tool can fix problems with broken frames?

I wouldn't be surprised if a lot of these issues come from files from torrents where the one of the pieces never got completed - usually because someone didn't download any text and html files and missed part of the video file. So many 99.9% completed torrents...

Maybe source a new copy of the file if possible from a different source and with a different checksum?

I wish checksums were used more often automatically (or voluntarily) in filesharing to maintain file integrity. I remember doing filechecks on stuff from Usenet back in the early 2000s. Seems almost non-existent nowadays.

 

[Casshern2]

Have you tried remuxing into a different frame rate to see if that does it?

 

[ding73ding]

For a long time, could do nothing due to lack of ideas what the problem (and solution) is, A clue fell out from nowhere: someone's impressive home-made trailers got me to dabble in editing, in case perhaps one day I'd make a similar trailer myself.

I tried some ffmpeg ju-jitsu, thinking maybe to transplant the good audio from a low res MP4 to replace the choppy audio on the FHD file. I accidentally discovered if I demux the audio out of the problem file, and listen to it, it's completely fine!!!

It was a surprise but not totally, I had been hopeful that the choppiness come from a decoding bug not corrupted data.

Having extracted a good audio stream from a file with choppy audio was Excellent, The next and final step should be remux the video with the good audio. But it was not all smooth sailing, the result was a file that's 20 minutes longer than before and badly mis-synched audio and video after a few mins.

After a lot of trials and error, I found out the audio stream can be fixed by speeding it up 8.8%. And then try the math, 48.0/44.1 = 1.088 so the 8.8% difference must have come from a 48kHz (sampling rate) raw audio stream being mis-labeled as 44.1kHz, and then the player got confused and every second or so try to re-synch the audio stream to the video stream, causing the choppiness.

The release group grafted a online gambling ad to the beginning of the file, which plays correctly. Probably the ad had 44.1kHz sampling rate, and the JAV itself had 48kHz sampling rate and the release group concat the two audio stream without check/re-encoding. So I trimmed off the ad, demux the audio, re-encoded the video in h265 (what I wanted to do anyway), up-tempo the audio by 8.8%, mux the two streams back together. DONE.

Probably could be done more elegantly and losslessly, but I've had enough ffmpeg for a day.

 

[ding73ding]

Continuing and concluding this conversation with myself:

Just noticed another vid in my collection has this audio problem. Good excuse to work out a proper SOP.

First use ffprobe to investigate the problem file. It actually doesn't help directly but it gives some useful pieces of information: codecs for video and audio streams, video frame rate, audio sample rate, duration etc.

Second: demux the audio stream:

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -c copy SDNM-270.aac

I choose the AAC file extension to match the original audio codec. Now we have a pure demux operation, no re-encoding, no modification at all.

Third: listen to the AAC file, confirm it sounds fine. But the play time is 8838 seconds, 9% longer than the original video (8120 sec) and if you pay attention the AAC file sounds a bit lower pitch, but it's not super obvious by listening. 8835/8120 is very close to 48000/44100 with 44100 being the nominal sample rate of the problem file. So now we can confirm the correct sample rate should be 48000.

Forth: with the correct correction confirmed, there's now a choice to repair the audio stream two ways:

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -af "asetrate=48000" SDNM-270-f.aac

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -af "atempo=48000/44100" SDNM-270-f2.aac

The first method makes a correct audio file with the same sample rate as original: 48000
The second method makes a correct audio but re-sampled using ffmpeg's auto-select of sample rate which happens to be 44100. The nominal duration of either file is completely messed up (so ffmpeg isn't perfect).

Both methods re-encode the AAC audio stream but perhaps the first method is the closest to the original (for the OCD type). Otherwise I don't see a strong reason to prefer either one.

Five: now re-mux the corrected audio with the video stream from the original file:

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -i SDNM-270-f2.aac -map 0:v -map 1:a -c copy SDNM-270-f2.mp4

Confirm the new file plays fine, the video stream was copied, so no loss of quality.

In retrospect, all the steps could have been combined into a single command (two versions):

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -c copy -c:a aac -af "atempo=48000/44100" SDNM-270-f3.mp4

ffmpeg -i "I:\yav\bath\SDNM-270.mp4" -c copy -c:a aac -af "asetrate=48000" SDNM-270-f3.mp4

But that has to assume you already know for sure the correction is indeed 9%. If you aren't sure about the quantity, then my five-step SOP is more sensible.

Performance: re-encoding the audio stream takes just over 2 minutes (for a 2:15:20 video), all other operations (muxing/demuxing) are super-fast, limited only by your hard drive speed.