Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3 repacker (Read 611079 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 repacker

Reply #575
I've tried to make it compilable on non-Windows platforms, but I don't actually test them. If it compiles with only those 3 changes, I'm impressed! However, note that the SSE optimization is not used outside of Windows.

Would you like some patches and results? I am trying to package it for myself (as a first step).

Later, I may package it for Debian, which would cover a lot of platforms, with different endianness, different sizes for ints etc. But let's start small first.

Here is what I have so far:

It sounds like you made the right changes:
1) I renamed mfu_find_best_config to mfu_find_best_config_base a while back, so yes, that should change.


2) That function was used in an old version of the multithreaded code, but it was too slow so I used a different algorithm. I guess I left the old OS hooks in, though.

So, the whole code can be ripped apart? Smaller is better, as always.  I had just created a mini-stub for gettid (which is Linux specific) as:

Code: [Select]
+int gettid() {
+       return syscall(SYS_gettid);

Do you happen to have a github account? I can send you github pull requests with some janitorial stuff like this and, of course, I have fixed some variable definitions which were causing GCC to complain about unused variables (they were only used inside ifdefs for windows).

3) Since I don't compile the non-Windows ones I sometimes miss a few includes, and it clearly looks like that should have been included.

I'm willing to send you patches.

What sort of differences are there between the outputs? If everything works perfectly there should be no differences in the uncompressed output. However, one thing I learned very quickly in this project is that encoders sometimes do some quirky things that are handled differently by different decoders, so if they don't match up it could be one of many possibilities (most of which are benign).

I am not the original poster, but the build problems (not quality problems) that I am having are with versions 2.x of mp3packer. With versions 1.2x, I was (actually, am) having a wonderful time, especially when I use it with GNU parallel, which executes one process of mp3packer for each core/thread of my processors.

BTW, mp3packer (as is handbrake/x264) is a fine tool to see if you have heat problems with your CPU/system, while doing something useful.

MP3 repacker

Reply #576
Latest version 2.04 is much faster than 2.03 at running --ib but occasionally locks up. Trying this on a group of mp3s will cause it to lock up on different files. 2.03 does not lock up on the same set of mp3s. Happens with 32bit and 64bit versions.

** correction, 2.03 locks up as well. Also, doing it repeatedly on any random mp3 will eventually cause it to lock up.

Even more interesting, I got the 64bit version of 2.03 to lock up when displaying the help info (by giving no input file). It showed everything down to --help and then froze.

MP3 repacker

Reply #577
Here are my diffs:

diff -r mp3packer-2.04/mp3framehuffman-c.c pack_orig/mp3packer-2.04/mp3framehuffman-c.c
> #if 1

Instead of that, a better approach is probably to use the gcc builtin.

Code: [Select]
raw = _byteswap_ulong(*int_ptr) << s->bit_index;


Code: [Select]
raw = __builtin_bswap32(*int_ptr) << s->bit_index;

when using GCC.

The byteswap included in the !HAVE_BYTESWAP case doesn't really work on all architectures, so it's sadly probably more portable to use a GCC builtin than to have more #ifdefs. :-)

MP3 repacker

Reply #578
if you prefer use latest gui and latest encoder and latest 64bit encoder!

MP3 repacker

Reply #579
I nearly got down to 50 percent of original size on a track from this free download:

The .zip file is 107 581 440 bytes including a pdf and a picture, unzips to 141 000 002 bytes (!),  of which 135 015 653 bytes music, the music mp3pack'd (with -z) down to 101 115 525 bytes. 

Now I am getting curious: seven out of twelve tracks are, according to fb2k, lame 3.98r V2 at 320 (EncSpot says 319). Didn't even know that was possible. They compress down to 202 - the "worst", track 4, down to 162. (161 according to EncSpot - couldn't it for the sake of the wow factor had gone down to 159?)

The reason why I do play with mp3packer from time to time, is to see how much is wasted by senseless encoding at usually 320 CBR. But this ... what have they done?

MP3 repacker

Reply #580
I am guessing that they used the -B ( minimum bitrate) switch. I.e. Encoding to "CBR" using the VBR engine.  Probably encspot shows 319 because there is silent parts encoded at 32kbps.

MP3 repacker

Reply #581
Actually, the lowercase b sets the minimum and uppercase B the maximum framesize. So, yes, it's possible to use the VBR engine to make constant bitrate encodings.

MP3 repacker

Reply #582
Duh! How bad for someone responsible of the LAME documentation (i.e. me) to make that mistake...    Thanks for correcting me.

MP3 repacker

Reply #583
Ah. So if I specify -b 320, then Lame will (at least would for 3.98) not attempt to make any use of the top ~100? Audio is usually not too well .zip-able.

Edit: I was wrong about 320 "CBR" yes - it was "VBR". V2, it seems.

MP3 repacker

Reply #584
Let's see if this example is clearer:

A) -V0  ~ 245kbps
B) -V9  ~ 65kbps

C) -V0 -b 64 -B 64  = 64kbps
D) -V9 -b 256 -B 256 = 256kbps

C is probably going to sound worse than B (the encoder will try to keep a level of detail unachievable with the provided bitrate), but their size will be about the same.

D is going to sound like B* (the codec is given more bits than those that it requires, but won't make use of them other than for block padding, and padding tends to be lots of zeroes, easily zip-able), but the size will be like A.

* In --vbr-old, D could sound better than B. This reasoning comes from the fact the older method was determining which bitrate was appropiate for the expected quality for the concrete block that it analized and then encoded it. That's why originally, the --alt-presets had -b 128, and even in the LAME history we can see some of the earlier versions having -b 64 as the default, to prevent the engine from guessing too low of a value.
--vbr-new does not work like that.

MP3 repacker

Reply #588
"Must Have" tool for sets. Big Thank You for Great Work.

MP3 repacker

Reply #589
Personally I use a custom hacked version in wich I replaced version and padding with zero bytes in exe file. Compressing any MP3 files as archive gives best results. A good suggestion is remove padding in repacking the MP3 file.

Re: MP3 repacker

Reply #590
This project appears to have come farther:

It still needs work. The string manipulation code needs to be remade for OCaml 4.08.0 and newer, because those default to force enabling safe strings at compile time of OCaml itself.

Edit: Oh, crud, just noticed this topic was from 2014. Well, that repo is slightly newer than that. But it needs specially built OCaml to build the mp3packer binary.

Re: MP3 repacker

Reply #591
@kode54 how bizarre that I was just using this (via WinMP3Packer) this past weekend and even today. And just thought I'd check this thread to see last posts and here you are :-)

Re: MP3 repacker

Reply #592
For anyone looking at a Linux build, I made one !

MP3Packer, version 2.04, 64-bit, compiled with optimizations (-O3), statically linked (needs glibc), stripped.
Linux x86_64

Already tested, and it is completely lossless and compress quite well ^^

File is hosted here:

Compiled from source code:

All the links before are now dead, so I thought it would be great to share this!

Send me messages if the download link is dead.

Re: MP3 repacker

Reply #593
Thanks for building that!  FWIW, modern OCaml doesn't really like building this (due to the `--unsafe-strings` flag).  If anyone wants to figure out how to build it w/o that settings, I'd appreciate it, and will update my repo.

Re: MP3 repacker

Reply #594
I don't have the needed programming skills unfortunately, at least it compiles fine :) (we just have to build Ocaml ourselves in order to use `--unsafe-strings`).

Your message reminded me that I have a small update: use of `-flto`, compressed using UPX, and finally a static aarch64 build :))

The aarch64 build works on Android/Termux without any issue.
Both builds were compressed with `upx -9 --ultra-brute` 4.0.2, compiled statically with `-O3 -flto`, stripped and are generic architecture instructions.

I can't even attach them in this answer for whatever reason, so here are the links:

Again, if links are dead send me a msg

Re: MP3 repacker

Reply #595
I recently ran mp3packer -z on just over 1 TB of LAME VBR encoded files. Looks like it saved about 8 kb per file.

Re: MP3 repacker

Reply #596
Dear sound enthusiasts,
would you mind answering a few question related to MP3Packer?

a) How to repack VBR into CBR? I see no dedicated switch, but the possibility is mentioned.

b) The manual says -b stands for “minimum bitrate allowed for output” and its default is 0. Does this mean that a minimum bitrate of 32 (e.g. lame3995o uses it to encode silence) might become 31-0? The older players might not like.

c) What's the point of minimizing and maximizing of bit reservoir with -r and -R?

d) Is there a way to use it in the Foobar2000's conversion chain (i.e. without manual invocation via foo_run)?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: MP3 repacker

Reply #597
a) How to repack VBR into CBR?
Use the -i or --ib option to examine your MP3 to see the minimum bitrate required for CBR output. Subtract 1 from that number and then use it with the -b option and the resulting MP3 will be CBR. (Subtracting 1 selects unpadded CBR, which is usually what you want since it's slightly smaller.)

The minimum CBR bitrate calculations don't include the -z optimizations. If you use -z to repack a MP3 and examine it again afterwards, the minimum CBR bitrate might be lower.

b) The manual says -b stands for “minimum bitrate allowed for output” and its default is 0. Does this mean that a minimum bitrate of 32 (e.g. lame3995o uses it to encode silence) might become 31-0? The older players might not like.
It means the minimum allowed for the MPEG version, which is unpadded 32kbps if your MP3 file is MPEG-1 or unpadded 8kbps if it's MPEG-2.

c) What's the point of minimizing and maximizing of bit reservoir with -r and -R?
If you're going to cut your MP3s with a program that isn't aware of the bit reservoir, using -r to avoid the bit reservoir can prevent some audible glitches after the cut. Using -R to fill the bit reservoir might be slightly faster? The default behavior is -r if you use -b, or -R if you don't use -b,

Re: MP3 repacker

Reply #598
d) No. fb2k converts by decoding and encoding.
mp3packer rewrites the encoded signal in a different way.

I was playing around with this ten years ago, and found out that there were quite a few wasteful MP3 files out there (as if CBR320 isn't wasteful in itself I mean) - see reply 579 up there, for example.
But beware that mp3packer can cause you trouble at track transitions, if those are not done properly in the original file.
Including, destroy gapless playback. The thing is, mp3 players are not screaming bloody murder at every possible irregularity: they are playing on as best as they can. And sometimes they successfully gloss over errors. And then you don't want a different (and zealous!) application to discard what it cannot handle.
So, use with care.

Re: MP3 repacker

Reply #599
@Octocontrabass @Porcus Thank you, comrades. After a month of testing MP3Packer with VBR files created by the resurrected Helix MP3 encoder, I found that the benefit is negligible (unlike, for example, with Lame 3995o files). However, with the help of the diagnostic data that this app outputs, I managed to find a bug in the aforementioned encoder related to the unreasonably low bitrate in one frame, which was soon fixed by @Case.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data