Skip to main content

Topic: 11 Minute 13 Second MP3 Every Time? (Read 2727 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
11 Minute 13 Second MP3 Every Time?
Newbie to this site.  Been using RazorLame for several years to create MP3 files.  I use two templates, one for 320k VBR for music, and another for 128k VBR for on-line sources.  I recently recorded a 6 hour radio show in Wave format and created a 128k MP3.  Noticed that the MP3 file created was smaller than normal.  Sounds perfect, but is only 11 minutes 13 seconds long.  Tried the 320k template, same thing - 11 minutes 13 second long.  Tried a shorter (but still 2+ hour) Wave file, and same thing - 11 minutes 13 seconds long!  Anybody know what setting I've inadvertently changed, or how to fix?

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
11 Minute 13 Second MP3 Every Time?
Reply #1
Size of WAV file? More than 2 or 4 GB? Some programs choke on sizes exceeding those limits.

11 Minute 13 Second MP3 Every Time?
Reply #2
Size of WAV file? More than 2 or 4 GB? Some programs choke on sizes exceeding those limits.

Wave files are in that size range (few GB).  What's weird is that I've been successfully encoding files of this size to 128k VBR using the same software for YEARS.  Have no idea why it isn't working now.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
11 Minute 13 Second MP3 Every Time?
Reply #3
Is there anything else you can think of that’s changed recently? The fact that it happens with two files suggests something in RazorLAME or LAME itself rather than a peculiarity of one particular WAV. But if the setup has worked for you for a long time, it’s puzzling why it would stop now, at least without further information.

As an aside, there are no such settings as 128 or 320 VBR, particularly not the latter as 320 kbps is the maximal per-frame bitrate and thus obviously cannot be a mean bitrate for VBR. I’m not familiar with RazorLAME, so perhaps it’s using misleading nomenclature for -V settings. Any mean bitrates reported in such contexts are based on certain sets of material only and cannot necessarily be relied upon, so using bitrate-based names is inviting confusion and/or disappointment; this applies to all lossy codecs with true VBR modes.

11 Minute 13 Second MP3 Every Time?
Reply #4
No other changes that I know of.  I'm wondering if it's not something I did without realizing it.  Might try deleting and reloading the software.  About the only option I have left to try at this point.

Not sure I understand your comments about my VBR settings.  For converting Wave files from CDs that I rip, I have RazorLame set to create an MP3 file with a max bitrate of 320k and minimum bitrate of 128k and quality = 0.  Depending on the Wave file, it creates an MP3 file that shows an "overall" bitrate usually in the mid-200k's, sometimes less, infrequently more.  I don't use the average bitrate setting, as I hate the thought of wasting data space when it's not needed.  But, I don't mind commiting the space if the music demands it.  If I'm off track, please let me know, as I'm about 2/3 of the way through my 6,000+ CD collection, and have a lot of MP3 files saved on the drive that may need replaced!
  • Last Edit: 30 March, 2013, 06:23:13 PM by db1989

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
11 Minute 13 Second MP3 Every Time?
Reply #5
Not sure I understand your comments about my VBR settings.
It was just a general comment that descriptions such as “128k VBR” have little accuracy in reality, whereas “320k VBR” has none.

Quote
Not sure I understand your comments about my VBR settings. For converting Wave files from CDs that I rip, I have RazorLame set to create an MP3 file with a max bitrate of 320k and minimum bitrate of 128k and quality = 0.
Firstly, maximal and minimal bitrates do not define VBR quality levels. Those limits are the defaults for the high- to mid- quality VBR settings, so they are effectively meaningless on their own without a quality level to aim for. There must be a numbered -V setting that RazorLAME invokes, and I would hope it allows the user to choose it. Secondly, -q0 (quality 0) is actually advised against; the default nowadays is -q3. Perhaps our article on LAME would provide more insight on the recommended settings as well as what RazorLAME might be trying to do.

This doesn’t mean that your files are suboptimal or need to be re-encoded, or even that RazorLAME is encoding inadvisably; as I said, with no experience of RazorLAME, I can’t say for sure. Still, you would be well served by a better understanding of what’s going on behind-the-scenes with LAME itself.

Anyhow, if you can’t think of any other way to attempt to solve the problem, let us know if the reinstallation somehow fixes things. First I would recommend checking other files, though, including ones that you have encoded successfully in the past (if you still have the uncompressed originals).

  • lvqcl
  • [*][*][*][*][*]
  • Developer
11 Minute 13 Second MP3 Every Time?
Reply #6
Quote
Secondly, -q0 (quality 0) is actually advised against

The name of -q option in RazorLame is "q level", and "Quality" is for -V option.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
11 Minute 13 Second MP3 Every Time?
Reply #7
Thanks for the correction. So, the files should be -V0, or roughly equivalent, since normal LAME without a minimal bitrate of 128 kbps (i.e. without -b128) would allow frames of 32 kbps for digital silence (although that shouldn’t matter too much).

Controlling quality level via the -V setting is infinitely preferable to lowering the maximal bitrate (-B), in case anyone has done the latter in hopes of getting ‘256 VBR’ and so on, the latter of which will inevitably reduce the ability of LAME to do its job and thus reduce the quality of the resulting files.

  • Aleron Ives
  • [*][*][*]
11 Minute 13 Second MP3 Every Time?
Reply #8
ALL2LAME is a better frontend to use with recent LAME releases, as RazorLame is no longer developed and is incapable of displaying the LAME histogram information. It is theoretically possible that further incompatibilities with LAME 3.99 are the cause of this problem (the histogram broke in 3.98.x, IIRC), but it seems unlikely.