Mar 15 2005, 02:33
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180
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 7Z file (version 2.04) (mirror)
Extract 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 (mirror).
* 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
* Now supports Unicode file names and paths
* Support for encoding an entire directory of files
* 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!)
* The 32-bit version will not process files larger than 1GB. The 64-bit version has a much higher limitation (4EB) which is unlikely to be encountered.
* There seems to be an incompatibility with the multi-threaded repacking code and 32-bit Windows XP. If you run across an error, try adding "--workers 0" to the command line.
Changelog (click here!)
This post has been edited by Omion: Sep 1 2012, 04:34
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
May 16 2005, 07:34
Joined: 16-May 05
Member No.: 22086
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:
QUOTE (Omion @ Mar 15 2005, 02:33 AM)
If LAME decides a frame needs more then 320kbps, it will take the needed bits from the bit reservoir.... As of version 0.03, very large frames are identified early enough to pack the reservoir dynamically.
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:
Name: MP3 Packerwith "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 ?
Parameter: /c "cd /d "E:\Backup\Programs\MP3 Packer\MP3 Packer v0.04" && perl mp3packer.pl -mst "%_path%" "%_folderpath%\%_filename%vbr.mp3""
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
|Lo-Fi Version||Time is now: 29th March 2015 - 05:00|