0

Edit: it's 0.0330s delay, not half a second sorry. ALso the problem occurs when converting the wav to .m4a in ffmpeg using the basic ffmpeg -i input.wav output.m4a, and I used the newest release of ffmpeg for that.

I had a large number of audio pieces as .wav s16's and I mixed those down into a single .wav f32 track. I then wanted to export this track to an aac with highest bitrate (320 seems to be highest audacity allows) in order to place it in an .mp4 container (is this the highest quality codec I can convert to and fit in a mp4? I want the highest audio quality I can get).

When I follow the instructions and export it creates a sync delay by about half a second or so...enough to give a noticable echo when they are played in tandem. I corrected it manually in audacity with my eyes. But when I export....it puts it out of sync once more, and I'd also rather avoid the loss generated by exporting an aac as an aac.

Is there a fix I can do using audacity (using newest version 2.3.0) or some other freeware program? I have ffmpeg command prompt, and handbrake, if there's a command that can manually trim the audio or assign the right alignment.

I notice audacity uses ffmpeg 2.2.2 version, and ffmpeg has many newer versions since then...could using those newer versions fix the issue maybe? Under preferences library it says:
ffmpeg library version: F(55.33.100),C(55.52.102),U(52.66.100)

And how would I make audacity use the newer versions? I don't really understand if it just calls up ffmpeg or if it needs to be this 2.2.2 version because they designed it to allow and work with that version specifically.

You can see how I exported the original .wav file in the picture below:

enter image description here

0

This is more a workaround than an answer as I did not manage to link the libavformat library to Audacity. So here are some clues using FFmpeg version 4.1 with libavformat.58.20.100.dylib on macOS.

There is a potential issue depending on the container used and the FFmpeg version. Some containers (m4a and mp4 for instance) include a metadata describing how many silent samples are to skip when decoding the aac bitstream. At least recent versions of FFmpeg are able to use this metadata.

Example test

  • Create a test track within Audacity
  • Export the test track from Audacity as wav PCM 24 bits 48 kHz export.wav
  • Use FFmpeg from the command line to create three test files:

ffmpeg -i export.wav c:a aac export_aac.aac

ffmpeg -i export.wav c:a aac export_m4a.m4a

ffmpeg -i export.wav c:a aac export_mp4.mp4

  • Use FFmpeg from the command line to convert back these three files to wav:

ffmpeg -i export_aac.aac export_aac.wav

ffmpeg -i export_m4a.m4a export_m4a.wav

ffmpeg -i export_mp4.mp4 export_mp4.wav

  • Import the three wav files in Audacity

  • Look at the screen capture below. m4a and mp4 files have been decoded by FFmpeg without silence, whereas the aac file has silence at the beginning.

Audacity screen capture

So a workaround for your use case might be to export all your files as wav from Audacity and then use FFmpeg to create the mp4 files.

  • OP reports "delay by about half a second or so". There's one priming frame at the head, so that's 1024 samples for AAC. For a 48 kHz stream, that's 0.021s. – Gyan Nov 25 '18 at 19:52
  • @Gyan : do you mean the 0.021 s delay that can be seen in the screen capture is not related to the OP's issue ? – audionuma Nov 25 '18 at 20:50
  • Sorry it's actually the case where the aac file is playing 0.0330s later than the original wav file. So that's alot less than half a second. Also I applied the basic ffmpeg -i input.wav output.m4a in the latest version of ffmpeg and the delay was the same as found in audacity. So from what I can see the problem is ffmpeg, as the audio sync issue shows up when checked in other programs other than audacity. – kite Nov 26 '18 at 1:55
  • @audionuma actually, it is - the OP reported a much longer delay initially, since corrected. – Gyan Nov 26 '18 at 4:55
  • To the OP, use ffmpeg to directly convert to AAC in a MP4 container because 1)the AAC encoder that Audacity uses is bad and in fact, no longer supported by ffmpeg. 2)ADTS streams (.aac) are raw and can't store priming skip, so the decoder will process and emit the initial silence. – Gyan Nov 26 '18 at 4:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.