• SONAR
  • Cakewalk's MP3 encoder problem. Is there a fix? (p.3)
2013/11/26 17:28:00
joden
It is a "pot luck" situation with VBR and Sonar mp3 encoder. I have done 5,6,7 in a row with no issues, but then 8, 9 and 10 WILL start showing as running for 12 minutes and longer (for a 3 minute file).
 
For some reason the mp3 encoder hiccups on VBR files? I have not noticed the same issue with fixed rate mp3's. That app I mentioned is free open source, and does heaps more than just VBR header fixes...check it out
2013/11/26 18:36:02
bitflipper
mettelus
I am glad you chimed in, since I do not understand the structure of these files. I have only tried this test once, and Windows Media Player "failed" on three different files. Are you implying that Windows Media Player reads Audition files properly for you? 
 

MP3 files (like all lossy-encoded file formats, as well as lossless FLAC) consist of a sequence of discrete data blocks. With CBR, all blocks are encoded identically and are therefore all the same size (as determined by the quality setting) regardless of content. VBR allows each block to be encoded at a different quality, so that quality can be adjusted up or down (within limits you specify) as needed based on the complexity of the audio within a given block.
 
It might seem that cheap storage and broadband connections have made VBR obsolete, but that wouldn't be entirely true all the time. Sometimes, you do care about file size. For example, I use VBR to get files under the 10MB limit imposed on a free SoundClick account. Other free file hosting sites such as SoundCloud don't limit individual files but instead give you a fixed disk quota for all files. And whenever file size does matter, VBR will generally yield higher fidelity than CBR at medium to low quality settings.
 
Of course, if you're hosting files yourself or just copying them to your MP3 player, then just make them all 320 kb/s CBR and forget about it.
 
I just did a test to make sure I wasn't blowin' smoke about Audition-encoded files...I loaded up a half-dozen VBR MP3s that I'd encoded with Audition and played them with Windows Media Player. It correctly reported the running time for each one.
2013/11/26 19:24:18
mettelus
Hmmm... so I am most likely missing codecs for WMP?
 
Edit: Actually I just opened and looked around the options/updates, etc. and it says I have the most current version and no updates are needed. Now I am lost. CBR is "good" for me
2013/11/26 19:37:44
bitflipper
No, not a missing codec. WMP is just reading a tag that LAME either doesn't write or doesn't write in the correct format for WMP to understand. Here's an MSDN article that explains it: http://support.microsoft.com/kb/306507
 
This behavior can occur if the .mp3 file was encoded at a Variable Bit Rate (VBR). Windows Media Player requires that the TLEN (or total length) field of the ID3v2 tag is set correctly to determine the appropriate length of a VBR .mp3 file. If this field is not set, the Windows Media Player samples the first few frames of the file and then estimates a length.

 
If you don't already have Foobar 2000, grab it, it's free. Very handy for editing MP3 tags and lots of other things, including a "fix vbr mp3 header" feature that appears to correct incorrect TLEN tags. It takes awhile to run, so I assume it's actually counting block sizes to get an accurate total.
2013/11/26 20:14:59
mettelus
Thank you! What a name to choose for a program FUBAR... er... Foobar :)
 
I exported the one VBR mp3 in Audition 4 (came with CS5.5) using the "Highest quality 44.1kHz VBR" but WMP opened it as 23 minutes (for a 3:22 song), which is why I had asked that question.
2013/11/27 01:37:58
LHong
 

Fraunhofer decoder incompatibility
Differing interpretations of an unclear portion of the MP3 spec led to certain versions of the Fraunhofer IIS MP3 decoder being unable to properly play certain MP3s created with certain versions of LAME.
In order to demonstrate the problem, the problematic MP3 must have been created with LAME 3.97 or earlier, and must contain a frame with certain parameters and a very large amount of data, such as a 320-kbps frame which makes heavy use of the of the bit reservoir. The decoder must be the DirectShow filter l3codecx.ax version 1.5.0 or lower. That filter is the decoder used by Windows Media Player. The filter was upgraded to 1.6.0 by an August 2010 security update, the newer version can play the problematic MP3s.
 
A workaround was implemented in LAME 3.98.0 beta 1 through LAME 3.98.2, and in LAME 3.99 alpha 1, whereby 320-kbps frames were limited in how much of the bit reservoir they could use. This resulted in wasted space when the bit reservoir would grow beyond the limit. In LAME 3.98.3 and beyond, and in LAME 3.99 alpha 2 and beyond, the method was changed such that the bit reservoir can't grow beyond the limit.
 
More info:
 http://wiki.hydrogenaudio.org/index.php?title=LAME#VBR_.28variable_bitrate.29_settings 


 
Try the latest version of LAME Encoder 2.99.5 - it might solve the issue!
 http://www.free-codecs.com/Lame_Encoder_download.htm 

 
 Good luck!
 
 
 
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account