Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#251248 - 07/03/2005 08:17 Bogus bitrate problem
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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?
_________________________
-- roger

Top
#251249 - 07/03/2005 09:00 Re: Bogus bitrate problem [Re: Roger]
image
old hand

Registered: 28/04/2002
Posts: 770
Loc: Los Angeles, CA
try with dbpoweramp. initial guess is probably something wrong with the piping support of windows.

Top
#251250 - 07/03/2005 09:30 Re: Bogus bitrate problem [Re: image]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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.
_________________________
-- roger

Top
#251251 - 07/03/2005 09:48 Re: Bogus bitrate problem [Re: Roger]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
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

Top
#251252 - 07/03/2005 10:29 Re: Bogus bitrate problem [Re: peter]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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.


Edited by Roger (07/03/2005 10:30)
_________________________
-- roger

Top
#251253 - 07/03/2005 10:36 Re: Bogus bitrate problem [Re: Roger]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
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

Top
#251254 - 07/03/2005 12:51 Re: Bogus bitrate problem [Re: peter]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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?
_________________________
-- roger

Top
#251255 - 07/03/2005 13:11 Re: Bogus bitrate problem [Re: Roger]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
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

Top
#251256 - 07/03/2005 13:24 Re: Bogus bitrate problem [Re: peter]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
Quote:
but it plain doesn't do the Right Thing for making MP3 files.


Writing to a temporary file it is, then...
_________________________
-- roger

Top
#251257 - 07/03/2005 15:36 Re: Bogus bitrate problem [Re: peter]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.


Edited by wfaulk (07/03/2005 15:45)
_________________________
Bitt Faulk

Top
#251258 - 07/03/2005 15:43 Re: Bogus bitrate problem [Re: wfaulk]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
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

Top
#251259 - 07/03/2005 15:46 Re: Bogus bitrate problem [Re: peter]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.
_________________________
Bitt Faulk

Top
#251260 - 08/03/2005 14:44 Re: Bogus bitrate problem [Re: Roger]
schofiel
carpal tunnel

Registered: 25/06/1999
Posts: 2993
Loc: Wareham, Dorset, UK
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.
_________________________
One of the few remaining Mk1 owners... #00015

Top