Bogus bitrate problem

Posted by: Roger

Bogus bitrate problem - 07/03/2005 08:17

Over the last month or so, I've been re-ripping my music to FLAC, and then transcoding to MP3 for transfer to the player.

I've run into a problem: emplode (and Rio Music Manager) are getting the bitrate wrong on these files. Windows Media Player reckons that they're around 115Kbps VBR, but emplode and RMM think that they're (e.g.) 32Kbps CBR.

This initially made me think that I had imminent hard disk failure. Because the bitrate is so totally wrong, the player doesn't seem to be caching enough of the track, and is getting caught out. Since my disk is taking a little while than longer to spin up, this is causing glitches in the music.

This is on my (unmodified) mk2a, running v3a8.

I'm using FLAC 1.1.1 and LAME 3.96.1 on Windows. I'm piping the output of FLAC into LAME, as follows:

flac -s -cd foo.wav | lame --quiet --preset standard - > foo.mp3

Ideas?
Posted by: image

Re: Bogus bitrate problem - 07/03/2005 09:00

try with dbpoweramp. initial guess is probably something wrong with the piping support of windows.
Posted by: Roger

Re: Bogus bitrate problem - 07/03/2005 09:30

Quote:
try with dbpoweramp.


I don't want to use dbpoweramp -- 'cos I'm actually doing the piping with a C# app of my own devising. It's just that the equivalent command line results in the same problem.

However, your suggestion does lead me to make the following discovery:

  • If I decode to WAV, and then encode to MP3, without piping anything, then the file is OK (174Kbps).
  • If I pipe the WAV into Lame, and write directly to a file, then the file is OK.
  • If I pipe the WAV into Lame, and use redirection on the output, then the file is broken.
  • If I read the WAV directly into Lame, and use redirection on the output, then the file is broken.


If I use the same command line on my Linux box (same version of Lame), i.e.:

$ lame --preset standard - - < foo.wav > foo.mp3

...then I get the same problem. So, it's a bug in Lame 3.96.1, when the output is redirected...

Quote:
something wrong with the piping support of windows.


...rather than a bug in Windows.

I guess I could just get my app to make Lame write the output directly, of course, but I'd like to get to the bottom of this.
Posted by: peter

Re: Bogus bitrate problem - 07/03/2005 09:48

Quote:
So, it's a bug in Lame 3.96.1, when the output is redirected...

The VBR header is at the beginning of the file. But Lame doesn't know what to write in it, until it's finished encoding the file. So on a non-seekable output -- such as a pipe -- it cannot write the VBR header. This isn't really a bug; you're expecting it to do the impossible. Any of the usual "vbrfix"-type programs should be able to add the header as a postprocessing step.

Peter
Posted by: Roger

Re: Bogus bitrate problem - 07/03/2005 10:29

Quote:
The VBR header is at the beginning of the file.


Agreed. My problem is that it appears to be writing a completely bogus one, where writing none at all would seem to be a much better plan.

Or is it that it's not writing one, and that RMM/emplode are simply picking up the first frame's bitrate and assuming it's the same for the whole file?

I'll look at cobbling together a vbrfix-like step for my app, I guess.
Posted by: peter

Re: Bogus bitrate problem - 07/03/2005 10:36

Quote:
Or is it that it's not writing one, and that RMM/emplode are simply picking up the first frame's bitrate and assuming it's the same for the whole file?

That sounds more likely.

Quote:
I'll look at cobbling together a vbrfix-like step for my app, I guess.

Is that easier than just getting Lame to write to a file instead? Your files won't play back gapless if Lame can't write its headers.

Peter
Posted by: Roger

Re: Bogus bitrate problem - 07/03/2005 12:51

Quote:
Is that easier than just getting Lame to write to a file instead?


No, but it makes other things I'm planning to do with this code harder.

OTOH, thinking about it, if I need to do a second pass for the vbrfix-stuff, I think I'll need a temporary file anyway.

Quote:
Your files won't play back gapless if Lame can't write its headers.


Lame-specfic ones, or just the VBR header that I'll add myself?
Posted by: peter

Re: Bogus bitrate problem - 07/03/2005 13:11

Quote:
Lame-specfic ones, or just the VBR header that I'll add myself?

A Lame-specific (or at least Lame-invented) one which can't be added later, as only the encoder can know what to put in the delay fields. Lame's ability to output to a pipe isn't exactly a misfeature (it's got certain very specific uses, such as streaming) but it plain doesn't do the Right Thing for making MP3 files.

Peter
Posted by: Roger

Re: Bogus bitrate problem - 07/03/2005 13:24

Quote:
but it plain doesn't do the Right Thing for making MP3 files.


Writing to a temporary file it is, then...
Posted by: wfaulk

Re: Bogus bitrate problem - 07/03/2005 15:36

3.96.1 won't do VBR heards and nogap at the same time anyway. I had them fix this (based on previous information from Peter, I think), but I think it got added after that release.

Edit: Nope. You have to use the --nogaptags flag to get it to write the headers. I forgot about that.

Reedit: Peter. Not Roger. I keep doing that, even though I've now met you both in person. At the same time. Sorry guys.
Posted by: peter

Re: Bogus bitrate problem - 07/03/2005 15:43

Quote:
3.96.1 won't do VBR heards and nogap at the same time anyway. I had them fix this (based on previous information from Roger, I think), but I think it got added after that release.

Players such as Karma and car-v3, which understand the Lame info tag, can produce gapless playback even without --nogap. Unless, that is, the file has been created as Roger originally described, which leaves Lame unable to write the info tag.

The info tag is useful even if you are using --nogap, as it also includes a frame count and CRC which can be used to check file completeness and integrity.

Peter
Posted by: wfaulk

Re: Bogus bitrate problem - 07/03/2005 15:46

Ah, I didn't realize that. Very cool. Another reason for me to use v3 more -- nogapping tracks without even having to reencode. Maybe it'll fix my display, too.
Posted by: schofiel

Re: Bogus bitrate problem - 08/03/2005 14:44

On the V3A8 release, I had a number of WAV tracks that were correctly identified for data rate and sample width on WINAMP, but on the player played back at double speed. They were also incorrectly identified on the player (visible in emplode) which John G and Peter thought was suspicious when I mentioned it to them (they thought the player was defaulting to some standard setting). Never followed up, sorry.