I’m having issues with the track lengths on MP3 exports. I’m exporting a multi-track podcast project with music and conversation. The file plays fine in Audacity, but when I export to MP3 some issues arise:
The given track time (i.e., when I play the file in iTunes) matches the total project time that I see inside the program.
But when I scroll to the end of the track, there’s still time left in the actual audio file. The time counter will count down to zero and then the track will keep playing. You can hear the audio until the end, but this inaccurate time code creates problems when the file is then being uploaded to various podcast players, including the iTunes store.
I saw one older post on the forum where a user described this issue (i.e., in the exported file, the play timer would count down to zero but there would still be time/sound left in the file), and the solution posted was to export as a constant bit rate MP3. I tried doing this and got the exact same result: a file that counts down to zero before it is actually done.
How do I export MP3s that are the exact same length as what I’m seeing/hearing in Audacity and that do not prematurely count down to zero when played?
Attached is a screenshot of my completed Audacity project.
It’s not an actual multi-track when you deliver, right? Audacity smashes everything together into one mono track?
Could this be the MP3 timing problem? MP3 can add some time to the length of the show. If it does that at the beginning, the show is actually longer than you think it is because it didn’t start on time. Could that be it?
Hello Koz – you might be right! I tried exporting as an AIFF file, and the issue seemed to be fixed. Then I converted that file to an MP3 in iTunes and it seems to be working OK. So there’s just an issue with the way Audacity encodes MP3s?
Audacity doesn’t encode MP3. It turns the work over to the Lame software that you had to install as a separate tool. Lame, in turn, is a simulacrum of the until now licensed software from Fraunhofer-Gesellschaft. Anyone could play an MP3, but you needed a license to make one. Couple all that with MP3 being part of a video format. MP3’s full family name is MPEG1 Layer 3 (or just MPEG Layer 3).
I always thought MP3’s insistence on waiting for non-existant video framing information resulted in the timing problems, but maybe not.
If you want to get an idea just how darn much fun all this is, search the forum for all the people trying to make an MP3 seamlessly loop.
“How come my MP3 loops never line up right?”
That brings us to the recommendation never do production in MP3, although this isn’t your particular problem. You and the audiobook people are kind of of stuck submitting in MP3.
I’m pretty sure that that’s exactly what Apple did - and that’s why, when I was converting my LPs, that I exported WAVs from Audcaity and then used iTunes to convert to MP3. That way there was no doubt about the legality, as Apple had paid the license.
If you think of the MP3 encoder as a black box, with a series of numbers (the sample values) going into the box, and a stream of numbers (the MP3 stream) coming out of the box, there are less numbers coming out of the box than going into the box, thus a reduced file size. In order to do this, the black box must calculate each output value, based on a bunch of input values.
As you can probably imagine, there is a delay between samples going into the black box, and data coming out of the black box. This is called the “encoder delay”. Similarly there is also a decoder delay.
More recent lossy compression formats (such as Ogg Vorbis), precisely define the overall encoder/decoder delay as a specified number of samples. Thus, when decoding an Ogg Vorbis file, the “dead” samples produced by encoder/decoder delay can be discarded, and the audio will start at exactly the right time. Unfortunately, when MP3 was invented, they did not consider encoder/decoder delay, or did not think it was important, so the delay is not defined. Because the delay is not defined, there is no way for the decoder to accurately know when the real audio starts (how many dead samples to discard).
Some modern MP3 encoders improve on the original format, by calculating the encoder delay, and writing it as metadata, which can then be taken into account by the decoder, but this is non-standard (not an official part of the MP3 format specification). For standards compliant MP3, you just have to put up with its limitations.
when MP3 was invented, they did not consider encoder/decoder delay, or did not think it was important, so the delay is not defined.
Waste of effort. Timing is built in to the associated video.
I have friends who tell of sharing movies in MPEG1 as a pile of CDs, not DVDs. If the pile was old enough, nobody got to see the end of the movie because that CD was on the bottom and always got scratched.
