I have just released the first public version of 'mp3tool' for Linux.

This is a command-line utility to examine .mp3 ID3 fields and headers,
and includes various options for certain manipulations.

It is also capable of FIXING bad/corrupted VBR headers,
so that FF and REW work again on the Empeg player.

Free for downloading (Linux x86 only, for now): http://rtr.ca/empeg/

-ml (Linux kernel dude)

The link on your website to download mp3tool appears to be broken...its downloading a text file full of jibberish. This sounds very interesting to me. How exactly does it fix the VBR header?

-steve

its downloading a text file full of jibberish

If your browser appears to download a text file full of gibberish, it's because the server doesn't recognize the file as a MIME type and it's serving it to you in text mode. Use an alternate browser or GetRight to retrieve the file.

Actually, in some cases, it's enough just to hold down the Shift key while you click on the link. But GetRight is a great tool anyway and you should try it.

___________
Tony Fabris

Actually...I did use right click...to download the file directly...to bypass MIME stuff...and it saved the files as mp3tool.txt. I have no idea what its supposed to be. Tar file? gzip file? binary? Its definitely not supposed to be a text file. Have you tried the link?

Actually...I did use right click...to download the file directly...to bypass MIME stuff...and it saved the file as mp3tool.txt.

Ah. It's not text gibberish, then.

One thing that Windows programs like to do (especially web browsers- I don't know why) is to force-assign a file extension onto the file if it doesn't have one.

Linux files often have no extensions. You've probably got a binary executable there that's perfectly good and just needs to be executed at the linux command prompt by typing its name. Just rename it without the extension.

I didn't try the link because it's Linux stuff and I don't run linux. But the "forced file extension" problem sounds like what you've got there.

___________
Tony Fabris

That's certainly worth a try...I'll try it now. Does anyone know exactly what he would have to do to FIX VBR headers?

bingo...that was it.....its a binary...and seems to run under linux.

Can if I can just be sure its not going to mangle my files....

Can if I can just be sure its not going to mangle my files....

Shift-click works OK in Netscape. Except it sometimes does stupid things with gzip-compressed files - it decompresses them but leaves the .gz extension on the filename. That's just annoying, though, the uncompressed file is still OK.

Try the "file" command on Linux, it tells you what kind of file something is:

aero:~> file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped

Regards,
Borislav

You need to go through the file and get the byte position of each %tage point of the file - ie, 1%, 2%, 3% (in time terms) then convert this to 256ths of the file length: this is the index.

Also, you fill in the length in frames (ie, time) & that sort of thing. You scan the whole file and update the small header on the front of it.

Hugo

Hmm, ok that part sounds pretty basic. Then it writes it into what kind of header? Is this the Xing header that I've heard about? Seems pretty straightforward. I guess I'll try his program on some test files....make sure it works ok..

It's pretty safe to use.. and it doesn't try to fix REALLY BAD files.

The --repair option (fix VBR headers) looks for an existing VBR header
and "repairs" it if necessary by recalculating the data for it.

I wrote/use the utility to strip the ID3V2 (--remove option) tags from all
of my .mp3 files prior to downloading the the empeg player -- they just
waste space on the empeg, and some of the tags are rather large image
files and text lyrics and whatnot.

Then I noticed that the FF/REW functions didn't work on my latest batch
of encodings.. the newest RealPlayer+ software from RealNetworks
(owners of Xing) writes broken headers to the files it creates.
Broken, as in all-zeros, for the 1/256 offsets in the VBR header.
So, I recently added code to decode .mp3 headers, recalculate the
VBR info, and repair it if specified.

As a bonus, the software looks for other errors (bad headers,
excess data, etc..) and reports it (but does not try to "fix" it).

As a side effect of this work, the program now reports the average
playback bitrate of VBR encoded files. Say you use "128kb VBR" to
encode some tunes: this is just a guideline to the encoding s/w,
which may actually use rates as low as 24kb/sec or as high as 160kb/sec
(or more). The mp3tool utility will compute the average overall rate
and dump it out to satisfy curiosity -- if you see your "128kb" files
are only averaging "110kb", then you know it's time to turn up the
quality setting a notch or two on your encoding software.

Cheers

Mark

Any chance of source being released for this - or builds for other OS's? I, for one, would love to build/use this on Mac OS X (the platform on which I store most of my MP3 files). :)


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Hey another OS X guy. Howdy. Have you found a working mp3 encoder for OS X yet? I have not really looked around yet, but I know audiocatalyst (which I used to use) does not work.

-Mike

Have you found a working mp3 encoder for OS X yet? I have not really looked around yet, but I know audiocatalyst (which I used to use) does not work.

Well, I've actually had mixed results with AudioCatalyst; it works for me, but only if a) you don't mind Classic crashing after you've used it (seems to happen always), and b) you don't mind taking the chance that it will bring down Classic while you're using it (happens rarely).

But that's as an encoder - as a ripper, AudioCatalyst doesn't work because it can't see the CD-ROM as low-level hardware. On the upside, OS X has audio ripping built in: just open an audio CD in Desktop and drag the .aiff files to a directory, convert them to normal AIFF's (they're ripped as AIFF-C) using something like SoundApp, and then use AudioCatalyst to encode them.

Alternatively, SoundJam MP for OS X works fine for ripping and encoding in one pass, but I don't particularly like its encoder (in particular, I don't understand their implementation of VBR encoding).


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Ahhh, I had tried AC, but I did not know about the AIFF-C --> AIFF conversion step. I just ended up with a bunch of encoded static. Did not crash classic though. I will have to give it another shot. Hopefully someone will port lame.

-Mike

LAME (at least v3.86) builds just fine; all you have to do is remove "-lm" from the LIBS line of the Makefile, and "make CC=cc". Assuming, of course, that you have the OS X developer tools installed. If not, let me know and I can send you a binary. :)

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Hey, look at that. 3.87b builds fine too, all I had to do was disable the GTK analyzer stuff. Thanks. Now, how about a command line ripper? Any suggestions?

-Mike

Now, how about a command line ripper? Any suggestions?

You shouldn't need one; just use the files directly off the audio CD ("/Audio CD/Track <n>.aiff"), and specify "-x" on the LAME command line to have it do bit-swapping, and it should work fine. I haven't run extensive tests as far as sound quality goes, though.


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Sweet, I love it when things are drastically simpler that I had assumed! Now I just have to read the lame docs again so I can try to remember what options I should be using.

-Mike

There's actually one catch, though, which I discovered last night. Files encoded by ripping directly off the CD from the command line get a "click" in them at the beginning, because apparently LAME doesn't deal properly with the AIFF-C header when it's told to byte-swap, so it assumes that header is sound. Converting the files to normal AIFF with SoundApp (in Classic), and then converting the AIFF's using LAME, works fine, however.


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Hmmm, I was just about convinced that was a result of the computer speakers I was using. Isn't there a way to get lame to ignore some of the beginning of the file (like if you wanted to trim leading silence)? I would love to be able to avoid that extra conversion.

-Mike

If I come up with one, I'll be sure to let you know; but I've just been using SoundJam instead, to avoid the hassle. :)


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

> If I come up with one, I'll be sure to let you know; but I've just been
> using SoundJam instead, to avoid the hassle. :)

As far as I recall, OS X has the GNU version of "tail" installed. If so, and ich you know how many bytes the AIFF-C header has, you could use:

tail +<position>c <soundfile> | lame <options> > <mp3file>

Where
<position> is the size of the AIFF-C-header plus 1
<soundfile> and <mp3file> should be self explanatory.

cu,
sven
(MkII 12GB blue, #080000113)