When exporting multitrack to mp3 time of track is changed

[V-Solas1689]

Hi everyone.  I am not compute savvy at all so forgive me.  I created secer multi tracks and then saved them.  When I export them to mp3 the time of the track changes.  For example I got the track in the program at 55 minutes but after export it is 52.  I have no dead air before or after so why does it do that?  Any help?

[ryclark · Accepted solution]

But what length does the file actually play for? Does your file show the proper time if you re-open it in Audition?

Due to the way the audio data is compressed some playback software can report incorrect times, especially if you used VBR (variable bit rate) rather than Constant. This is because they try to calculate the time of the file using the amount of data against included metadata showing the sample rate and bit depth which doesn't always give the correct answer.

[V-Solas1689]

Yes when I open it in Adobe it is right at the 55 minute mark but when I send it in a Dropbox file it is 52 minutes.  So do I export it in a constant format or something? 

[ryclark]

As it is just a reporting error it depends how much it matters if Dropbox or any other software report the incorrect length. If you want it to show more accurately then, yes, by all means use CBR instead of VBR. However the file size may increase a bit for similar bit rate settings.

[V-Solas1689]

Ok thanks so much.  I appreciate your help and for you taking the time.  Yes is has to be an exact 55 minutes.  It is for a radio program.  So I will try the CBR and hopefully that will do it.  Thanks again.

[SukiW]

I am having this problem consistently but it's a bigger problem:

I create my podcast files exactly 29 minutes in length as required for a program I submit them to. They need them exact because they are using software that can't deal with files being over or under. My Audition multitracks are EXACTLY 29 minutes. However, when I export them, they are always 28:56 in a player, though the file believes it is 29:00. So I have to create my files to be 29:04 in order for their computer to recognize them as 29:00. When I make a 58:00 podcast, I have to create a multitrack file that ends at 58:05 in order to get a 58:00 MP3.

Explanation?

[SteveG_AudioMasters_]

Are these MP3 files?

[SukiW]

No, they are screenshots of what the files look like when I inspect them. Player believes that they are shorter than the file inspector believes they are.

[SteveG_AudioMasters_]

No, not your screenshots (they are not particularly relevent) - it's the format of the files you are creating I wanted to know about - are these MP3 files or something else?

[SukiW]

I am creating MP3 files from multitrack files in Audition.

[SteveG_AudioMasters_]

Then have you read and understood the implications of the rest of this thread? Are you using CBR or VBR encoding? Have you actually run one of these files and timed it independently to see how long it really is?

[SukiW]

I am using this setting in File/Export/Multitrack Mixdown:

MP3 192 Kbps CBR

[SteveG_AudioMasters_]

Unless you do the timing check, you still won't know if this is a metadata reporting issue, or the file has really shrunk. If you start a new multitrack session and import a wav copy (not an MP3) of the original mixdown on one track, and your decoded MP3 file on the one adjacent to it, it should be easy to tell if they are different lengths.

[SukiW]

Hi Steve, it's a metadata reporting issue. The time is exactly the same in both exports, WAV and MP3, when I bring them back into Audition. They match the time in my multitrack, as well. (BTW, the WAV's metadata is wrong, also.)
So my question is: the producer was happy with the "fake" 29-minute file that I created (which was actually 29:04 as created in Audition). But I'd really prefer to have Audition create files that have the correct metadata. Since I am not using VBR, are there any other possible culprits? And second question: Can I use brute force in the meantime and change the metadata to be correct?

[SukiW]

Also, we used ffprobe to look at the metadata and here's what it found:
"[mp3 @ 0x7f94e4904380] Estimating duration from bitrate, this may be inaccurate"

So it looks like Audition isn't actually encoding the duration, which might be the root of the problem. But since I have never changed these preferences, I'd have no idea where to start. Is there a preference I can look at to make sure that the duraction is being encoded in the metadata?

[SteveG_AudioMasters_]

Er, I'm afraid not. Thing is, Audition isn't encoding the information, because Audition isn't encoding your MP3 file. Audition uses the Fraunhofer encoder, and it's that that is estimating the time and writing its guess to the metadata. Nothing you can do about that, as a search of the internet will reveal - it happens with all encoders, and whilst there are several solutions available that will give you a more accurate answer for any given file, they all come to the same conclusion - which is that you need to replace the file's metadata. There's a thread about all of this, and doing that here. 

But be clear; this is not an Audition preference you can alter, because it's not Audition that creates the information; it's extracted during the encode/coding gain process. The fact that software like Sox can work it out is a bit moot - it can only do this after the event, not during encoding, during which the metadata is being created.

[SukiW]

OK, obviously I'm missing some link in understanding here but I will just give in! What you said above implies that the VBR issue this thread started with is not at all related to my problem. And that my problem is one that everyone has, not just me. So the guy above who had his issue because of VBR actually was still going to have the same issue with CBR. That really doesn't make sense, given that no one else my producer deals with has this problem. But if that's the answer, then I guess I have to go with it and learn how to alter the metadata. Or just stick extra silence at the end of my episode so their computer thinks it's the right length, which is actually easier for me and more straightforward. It's vexing in either case. Thanks for your help.

[SteveG_AudioMasters_]

I think that there's a very good chance that this is handled differently by different encoders. So other people, using different encoders (like LAME, for instance) may get more consistent, and accurate, results. Adobe went with the Fraunhofer encoder, because at the time it was the only one they could legally use - a part of all sales revenue went towards the license. There have been a lot of complaints about it over the years, and now that it's out of patent protection, I think it would be better if Audition allowed people to select the encoder of their choice. Another thing that can alter the reported time,  of course, is the bit rate you use. I would imagine that the higher this is, the smaller the errors are likely to be.

As for VBR vs CBR - well, CBR is always going to give a more consistent, if not more accurate result however you look at it, simply because one of the major error-inducing variables in the calculation has been removed.