Skip to main content


Please be aware that much of the software linked to or mentioned on this forum is niche and therefore infrequently downloaded. Lots of anti-virus scanners and so-called malware detectors like to flag infrequently downloaded software as bad until it is either downloaded enough times, or its developer actually bothers with getting each individual release allow listed by every single AV vendor. You can do many people a great favor when encountering such a "problem" example by submitting them to your AV vendor for examination. For almost everything on this forum, it is a false positive.
Topic: MP3 repacker (Read 504968 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?
High Voltage socket-nose-avatar

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.
High Voltage socket-nose-avatar

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 #585
[quote author=[JAZ] link=msg=856410 date=1390673993]D is going to sound like B*[/quote]


Obviously, allowing the user to do what the user asks, is far from fool-proof :-)
High Voltage socket-nose-avatar

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 :-)

SimplePortal 1.0.0 RC1 © 2008-2021