What it does:
Attempts to save space by storing frame data in the smallest possible frame. Usually MP3s are already stored in the most efficient way possible. However, for high-bitrate CBR files (like --preset insane) there can be a lot of wasted space

psyllium has made a great Windows GUI for this program. The GUI thread is here. Many people will find it easier to use than the CLI, and it has a few more features too (recursive directory support, 2-pass CBR).

How to use:
Download this RAR file (version 1.20)
UnRAR to a directory that makes sense.
Type "mp3packer in.mp3 out.mp3" to repack the in.mp3 file
OR see mp3packer.html included in the package (or available here) for more options.
The source can be downloaded here.

Features:
* Can make --preset insane files up to 10% smaller LOSSLESSLY (depending on the LAME version used)
* Squeezes out all the padding it can from any MP3 (Will not produce a larger file, unless you use the -b switch or something goes wrong)
* Writes valid LAME/XING header for proper VBR seeking
* Many people also use this backwards, to losslessly turn VBR into larger CBR files to humor players which can't handle VBR
* Includes a brute-force compression optimization option as of 1.10 to further compress files
* Finally works on directories again!
* Works on Windows, Linux, 64-bit Linux, Linux through WINE, and should work perfectly on any other platform with an OCaml port
* GPL, so anybody can tweak it as long as it stays GPL

A few caveats:
* The program will always output an MP3 that doesn't use CRCs, even if the input file uses CRC. This is primarily laziness on my part, but nobody really needs them, and it saves 600 bits per second... (it's a feature, not a bug!)

Changelog (click here!)

what about gapless playback? Will anything in the headers which is required for gapless playback be damaged?

- Lyx

Nope. Gapless settings are in the LAME tag, which is saved to the new file. The only LAME tag settings which I change are the ones that actually change (file length, etc.) Everything else is saved.

that's some pretty pimp stuff...does it handle files other than LAME as well?

Yup. If it's an MP3, it's supported. LAME is just extra-supported as the program handles LAME/XING headers properly.

I just noticed that MPEG2 and 2.5 files are having some sort of problem. I'll see if I can fix it sometime today. [Edit: MPEG2 / 2.5 files are working correctly as of version 0.02.]

Sounds pretty cool. I wouldn't have thought there'd be that much to squeeze out (I don't know much about mp3's), but if it works as well as you say it does (I'm'a have to see for my self ) and it doesn't damage playability I'm betting this will become quite the popular little app.

Thank you for all your hard work .

So, basically this program turns a CBR file into a VBR file, correct? Pointing newbies who don't understand/trust VBR might be interested in reading this!

Seems to work fine.
I just tested it on some random MP3 files and it shaved of a few kb of everyone of them.

Well, most of the time there isn't anything to squeeze out. But on some files, most notably high-bitrate CBR files, there can be quite a bit of dead space.

@solaris:
Do you know which encoder/settings were used for your test files?

Yes, although it would be slightly more accurate to say that it turns any MP3 into a VBR file.

... actually, there's still a possibility that the resultant file is CBR, but that's extremely unlikely. It would indicate that the input file didn't use the bit reservoir, which is quite bad for an encoder to do.

Hmm... I guess the most accurate way to characterize the program is:
* At every frame, it picks the smallest frame size which can hold all the data
or perhaps simply:
* In the resultant file, dependancy on the bit reservoir is minimized

Although both of these definitions can be invalidated if you use some of the command line options. It looks like my little Perl script is pretty hard to define

Binary, anyone?

Perl = script language = no binaries.

Someone who knows both perl and something like C can translate, but bla why bother. Here is the perl to get for windows. Install it, and then:
Run "perl mp3packer.pl in.mp3 out.mp3" to repack OR run "perl mp3packer.pl -h" to see other options

Well, you could use perlcc. Won't be as easy in this case because of the module that needs to be included. So you'd need to build the shared library first.

Then convert the mp3packer.pl to C

Then you can use gcc to compile the C code and statically link the library into it.

I think... I'm a bit rusty

Not sure if this would even result in usable output either.

They are lame --alt-preset standard. But there are some times since I encoded them, so I`m a bit unsure what lame version I used (probably 3.90.2/3 and/or 3.96.1).
I have no cbr files to test it on.

Wtf.
I'm using ActivePerl as recommended by Klyith, what am I doing wrong?

couldn't this funktion be put into lame ? some thing like -repack

just tried this. Saved a couple of bytes.
However the output is NOT the same

I used winamp diskwrite plugin.
Ran crc32 and md5 check on the files and they did not match,
also the size of the 2 decoded wavs where not identical either.

and id3v2 tags are removed from the file.

The way I'd describe the output of the songs I tried this with is almost constand 320k stream with the occasional flicker which is a 256k frame. Still pretty fun to play around with.

@Omion
Thanks for the great tool!



Is the wav from mp3packer shorter than the original? If so, it might be related to the last frame of the mp3 being truncated because of the removal of padding.
(just speculating, haven't tested mp3packer for myself, yet)

Omion, any idea?



Which saves another few bytes! Great feature for a packer, isn't it?

If you were using LAME-encoded MP3s, did you use a gapless decoder?

The file should have the exact same number of frames, with the same data in them, and the same gapless settings. If they're not, either the program's wrong or the decoder's not producing identical output. This may be the case if the decoder is using dithering, which will add random (not reproducible) noise.

@ sven_Bent:
If you have Foobar, run the "bit-compare tracks" function on the two files. If you don't have Foobar, then could you run the SAME mp3 through the Winamp diskwriter plugin twice, and see if they match up. (If they don't, then your output is dithering)

About the ID3V2 tags, the repacker doesn't save anything before the first valid MP3 frame. It only saves the non-MP3 data after the end. This means that some versions of the ID3v2 tag will not be stored. (I think 2.4 is stored at the end... ID3 tags are a mess... )

What version of Perl are you using? Run "perl -v" and it should say something like "This is perl, v5.8.5 built for MSWin32-x86-multi-thread"

Line 16 is where the first constant is defined.
Try saving and running the following:


The result should be something like:
(The array might have a different value)

If that doesn't run, then it looks like your "constant" library is screwed up... If it does run, then I'll have to try it out with ActivePerl, and see why my it doesn't like mp3packer.

I'm going to my parent's house tomorrow for a week, so I might not be as responsive as I should be, but I'll work on this as soon as I get things set up there.

@ominion

i dont have fobar her
but i did two diskwrites of the same mp3 as before (the original and not the repackwd)
and they came out bit identical

MD5
b526274595bd1b40fa744673c8b25f08 *first.wav
b526274595bd1b40fa744673c8b25f08 *Second.wav

CRC32
first.wav 75FDC377
Second.wav 75FDC377

So it definatly seems like the repack stuff is NOT lossless to the decoded stream

edit: nevermind - i misunderstood something.

I think I know the problem. Some versions of Perl don't allow multiple constants to be defined at the same time. It should be fairly easy to fix... I'll do it as soon as I can. [Edit: Should be fixed now. Download version 0.02 and try it out.]

I figured it out. It's actually probably Winamp's fault. My program outputs a VBR stream, and so adds a VBR header at the front. This header is designed such that programs which don't support it will simply see an empty frame.

Winamp suppports the header, but it still plays the frame as an empty frame. Therefore, Winamp will add an extra 1152 null samples to a file with a VBR header. If the input file to mp3packer doesn't have a header, then Winamp will add an extra 1152 samples to the output file (which always has a header), thus making the MD5 different for the decoded files.

At least, I think that's how Winamp works. Foobar thinks my two test files are exactly the same, whereas Winamp outputs files with different MD5s.

In order to make sure, I took the two Winamp output files, deleted the WAV headers of the 2 (because the files have a different number of samples, which is encoded in the header) then deleted the first 1152 samples (4608 bytes) of the file from my program. The resulting files had the same MD5. That indicates that Winamp's output is the exact same, except for 1152 samples added to the front. If that makes any sense...

Okay, version 0.02 works. But still with some issues…


<…>


Here it does massive BR overflow on almost every frame then halts and writes this:


The file was 9:23 track encoded (not by me though) in 256 kbps cbr (lame 3.91). Encspot doesn't report any problems.
What do I do now?

Try increasing the -p switch. It's 100 by default. Use "mp3packer -a 256 -p 200". If THAT doesn't work, then I'll need to do something about my frame-too-big handling. I'll start working on a better solution now... The problem is that, with many LAME encodes (especially CBR 256 -- you picked the worst one) the file might require at least n bytes in the reservoir, but my program tries to minimize the amount of bytes in the bit reservoir, so many times there's fewer than n bytes, so the program panics.

Encspot wouldn't notice any problems in the input file, simply because there really aren't any problems. It's just the way my program handles (or fails to handle) some files.

I'm pretty sure I can do some sort of "pre-pass" on the file, log all the frames which are larger than 320kbps, and try to only pad the reservoir right before them. I'll get to work on it, but I have no idea when it'll be done.

It works now, but only with -p 250 or more, the result is just stripping a few kbps.
Edit: “A few” = 2-8 kbps (tested on 224-256-320 kbps files).

I haven't had the chance yet to give it a try...but is it true that CBR files will end up as VBR files?

Hmmm... Do you know what program made the files? In my experience with both LAME and the iTunes encoder, CBR 320 files go down to around 290. I can believe that 224 won't give much improvement, though. The lower the bitrate, the more the files actually need all of it.


Yup. That's how it works. It uses the minimal size for each frame, which almost always results in a VBR file. (Just like I said in post #10 ) A valid LAME VBR header is written, so programs will handle it the same way as they do every VBR file, if that's what you're wondering.

By the way, I made a new version which intelligently figures out where padding needs to be placed, so you don't need to screw around with the -a and -p switches. The downside to this is it either has to read the file twice (goes almost half as fast) or store the entire file into memory (uses lots of memory) I'll post it once I finish testing it.

Just released version 0.03. Now you no longer need to fiddle with the -a and -p switches (actually they aren't even supported any more). It shouldn't complain about not having enough bits in the bit reservoir again.

I do recommend that you use the -m switch, as it tends to go about twice as fast. It crams the entire file into memory, so it's not good for large files. For standard 1-song-per-file MP3s it's fairly safe to use -m.

I get this error for one file

On frame 7435 of 7536 (98substr outside of string at mp3packer/mp3.pm line 996.

and the resulting mp3 has no header


Also, i find some 320kbps files that are not packed at all.

@Omion

Would it be possible to add a parameter to the m-switch where you can specify a value in megabytes. If the file is larger than the specified value, then it will not be loaded into memory, if it is smaller or equal then it will be loaded into memory. This could be useful for batch-repacking in the future when your tool becomes stable.

- Lyx

I also got the same error when I tried to re-pack a new-Xing vbr file (according to EncSpot).
However other 9 cbr files (also Xing, old and new) were repacked without errors.

BTW, I don't think that Perl is not a "real" programming language

Boys, please let me simply download .EXE without any compiling, well?
Would anybody likes to upload exe and put the link here?

Um, you don't need a repacker binary. Use perl to run it.

THAT's not good. Looks like I've made more bugs than I've squashed with the lastest version. I may have missed something whilst re-reading the XING tag spec. Can either of you send, say, the first 1KB of the problem file to me? I've PMed you my email address.

Unfortunately, I don't know how most people cut up a file, so I can't tell you how to send the first 1KB, but I'm sure someone here does. I use an old hex editor called "Hedit" which doesn't even exist any more, so it's not really of any use.

By the way, does this only happen with version 0.03, or does 0.02 do it too?
[edit:] Also, does the -m switch affect the problem? [/edit]

@Lyx:
Adding a cutoff value for the -m switch would not only be possible, it would be extremely easy and useful. I don't know why I didn't think of it before. I'll add it to the next version, along with the fix to this bug people are getting.

For chopping, I use dd from GNU coreutils.

dd if=input.mp3 of=chopped_file bs=1000 count=1

edit: If you're running Windows, MinGW, Cygwin, or GnuWin32 should let you run coreutils.

0.3 works good for me, thanks.

Sure, I'll send it in Monday (that file is on my office desktop).
Meanwhile I'll try to reproduce the problem on my home PC (if my wife allow me to go closer to the comp )

BTW, the problem could be with that file and not with your program. I even don't remember where I have downloaded it from.

Tony

Released version 0.04.

Hopefully the previous "substr outside of string" error has been fixed. Thanks, Antonski and kevinsham, for sending me the files that broke.

Also added a "-M" option, which has one argument. If the file size is smaller than the argument, in MiB, then the "-m" option is turned on. Otherwise, it's turned off.

There was another problem which may or may not have existed, but it definitely shouldn't exist any more. The calculation for the XING TOC was off by around 100 bytes, which may have caused the XING tag to overflow and corrupt the first frame on very small files.

Hi Reed,

I'm afraid I've encounered a new problem with repacker, this time workng on my old home sweet Win98SE. I have Active Perl 5.6.1.
After repacking of every file the program generates a message "Illegal division by zero at mp3.pm line 785." and there is no Xing header in the output file (as far as I can see).
There is no problem with Win2000 though.
If you are interested, I would send you the the headers of the original file and both outputs - correct and incorrect.

BTW, I really like that program a lot. And Perl

~Tony

@Antonski -
Hmm.... That's where the program divides by the size of the output file. Maybe win98 doesn't update the size of open filehandles or something. Try replacing your mp3.pm with this one. If that doesn't work, then I'll have to think of something else.

Works perfectly!
Thank you

I've been tinkering with v.0.04 using the latest version of Perl on Win XP. I'm getting pretty good results, even with 192 kbps CBR LAME files. But I have noticed two issues:

1. My original LAME files have proper LAME tags, but the new files have no LAME tags (so I am adding them manually via fb2k).

2. Encspot now reports the encoder used as Xing or Gogo but the original files are definitely LAME.

1. That's weird. If the input files have LAME tags, the output files should too. Otherwise, a simple XING tag is added. What version of LAME do you have, and how did you check if the files have the tag? It's possible that my program thinks the tag is incorrectly formed, and so just stores a standard XING tag. (If it doesn't write an XING tag either, that's very bad)

2. Well, the audio data is the same, so it shouldn't matter. Encspot just sees that the files are arranged differently from what LAME usually does, and guesses something else. The quality is the same as the original. (Except if a LAME tag is written, in which case EncSpot parrots the encoder string)

Sorry to resurrect this thread on my first post but I really do like MP3 Packer and had a few questions...

Omion I use your program on all my old --preset insane files to remove tags and in the process shave a few kbits off the filesize. Am I right in saying that it also strips off any "bad last frames" that it encounters (I think you confirmed this in an earlier post) ?

When I recently tried to repack a 192kbps CBR mp3 Encspot showed the outputted file as having 224, 256 or 320 kpbs bit rates for some frames. Is this possible ? Is the mechanism similar to:
I sincerely hope you are still developing this great little proggie, batch processing and perhaps an executable and a GUI would be very welcome indeed although I am perfecty content with the app in its current form (if anyone reading could compile MP3 Repacker into a stable binary or show me how to go about it I would be eternally grateful ). As it is I currently use Florian's amazing MP3Tag program with mp3repacker inserted as a tool like so: with "for all selected files" ticked. Provided the user adjusts the absolute path to the two MP3 Packer files accordingly then it allows any number of mp3s in a directory to be packed to output files in the same folder but with vbr appended to the end of the filename by simply highlighting the mp3s, right clicking and selecting the MP3 Packer tool. This pseudo-batch processing comes in quite handy so I hope those instructions help anyone else in the same situation as me. Omion I was wondering if you could tell me if it's "safe" to run so many MP3 Packers concurrently ?

Lastly I was hoping you could tell me if you are aware of any bugs that would make running Mp3 Packer on all of my old unreplaceable mp3s a bad decision...

Thanks for all your hard work and effort

--asonicboom

If a bad last frame is encountered, it is simply added to the "non-MP3 junk at the end" category. That means that if you use the -s option the bad frame will be thrown out, otherwise it will be included but not optimized.
It is possible, expected, and happens quite a lot . Due to the bit reservoir, the amount of data stored in an MP3 frame has very little relation to the bitrate of that frame. For example, here's a graph of a 192-CBR file. The red is the size of each frame (constant, of course) but the black dots are the actual amount of data in each frame. The blue is how many bits are in the reservoir per frame.

You can see that the bit reservoir is relatively large compared to the frame size; this means that data for one frame is far away from the actual frame header. The output of my program, though of similar size, has a much different structure:

You can see that there is less data in the reservoir, and the frames have sizes from 32-320kbps, depending on how much actual data there is. The top row of red dots is 320, the next one down is 256, etc.

I've been trying to figure out how to make binaries from Perl, but my Perl doesn't seem to want to.

I don't have any experience or desire to make a GUI for the program, but if you want to, feel free .
As long as you don't have them writing to the same file, running multiple repackers in parallel isn't a problem. (If you do have them writing to the same file, they won't corrupt it; they'll just exit with a "permission denied" error)
I don't know of any bugs in the program; it seems fairly stable. However, if you want to extra assurance, you can run the input and output files through Foobar's "bit-compare files". If that says they're OK, then you can delete the old one. If it says they're different, then post to this thread, as it would indicate a bug.

Thank you for the feedback! It's good to know that people are using my program.

Thanks for replying so soon and so comprehensively Omion, your answers were very helpful Again good work on making such a great little program. Will do Till then...

--asonicboom