Cakewalk's MP3 encoder problem. Is there a fix?

Cakewalk uses the LAME encoder. I recall a similar post some time ago. I am not sure what the resolution was. I could not replicate the problem and am not sure what the cause of the problem is but it may be content related. The only thing I can offer is an updated version of the LAME encoder used by Cakewalk. Another user kindly recompiled TTSLame with a newer version of LAME. The files are posted here.

I have played the files in Windows Media Player and the built-in player in my Android phone.  The timing is messed up in both.
 
scook, are you recommending an update to the LAME encoder used by Cakewalk's MP3 encoder?  Or to ditch the Cakewalk encoder entirely and configure LAME as an external encoder?  (I've had mixed results with that method)

The link I provided is an updated version of the encoder Cakewalk supplies and can only be used by those that have purchased the original encoder from Cakewalk. It might make a difference. The other thing to try is exporting the file as a wave and using a different encoder to verify the problem is with vbr encoding in LAME. I don't do much with mp3 so probably not going to be much help with this particular problem. As I said there was a similar thread about 6 months to a year ago but I don't remember the details. If I find a the thread, I will post a link to it.

That is true but it is a newer version than you are running now.
 
Maybe another cleaver user would like to take a stab at updating the library but until that time, the ones I pointed to is the most recent available.

Thanks for that scook!
 
I must say though, it is quite lame (pun intended) that Cakewalk charges for an MP3 encoder, yet they don't update it. 

If it is an encoder problem, it appears that both Cakewalk and Adobe share the same problem. I tried to find the previous thread, could not find it on Google.

I did a third VBR in another program, with similar results... then I opened these mp3's with programs readily available in the "open with" command... (the three VBR mp3s were made with the TTSLame (above), Adobe Audition, and Protected Music Converter)
 
This is what happened when playing them:
   Windows Media Player & Movie Maker - opens but time bar is incorrect (length varies based on mp3 chosen as they were set to differing VBR settings)
   SONAR X3c - Ironically will not open any VBR mp3 if trying to "open with" X3 (says the file is corrupt), but does import them correctly into an audio track (all 3 VBRs) with the correct 3:22 timing
   Quick Time Player - hangs when try to "open with," program doesn't respond at all; but will open these files if Quick Time is already running (to the correct 3:22 timing)
   Adobe Audition - Will launch and play all three VBR mp3s with the correct 3:22 timing
 
   Pretty much a player issue... choose your weapons wisely
 

Studious
Thanks for that scook! I must say though, it is quite lame (pun intended) that Cakewalk charges for an MP3 encoder, yet they don't update it. 

Under the GNU open source agreements, for a commercial entity to include the lame encoder in a retail product there is a licence fee payable which is simply passed onto the end user as per the licence. As for updating it we are talking about a modest point release difference.
As the licence fees and other associated issues are not apply able for private non commercial use you can always use Cakewalk's simple instructions to setup the lame encoder yourself. Then you get it free and can update and use any version you choose.

i think that today, with less worry about storage space, CBR is the way to go (VBR was introduced to give even more compression/smaller file?) and fwiw, i always encode manually from a WAV (using razorlame) rather than as an export option from the daw

bitflipper
VBR files I've encoded with Audition all report correct running times.

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? (Granted, I have locked out WPM from updating itself, so I might very well be "codec light" here?).
 
For folks on Win7 and earlier, I would "assume" that the average user would have WPM set as their "default" mp3 player, which may be the concern with the OP.
 
I definitely agree with the recommendations for higher data rate at CBR. They convert faster as well on that setting, and storage these days is not a big concern.
 

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.

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.

 

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!