Skip to main content ↑ ↓

Notice

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 576450 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 repacker

Reply #575 –
Quote from: Omion on
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: https://github.com/rbrito/mp3packer

Quote
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.


Great.

Quote
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).

Quote
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.

Quote
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 –
Quote from: bugbear on
Here are my diffs:

diff -r mp3packer-2.04/mp3framehuffman-c.c pack_orig/mp3packer-2.04/mp3framehuffman-c.c
337c337
< #if HAS_BYTESWAP
---
> #if 1

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

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

to

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!
http://www.hydrogenaudio.org/forums/index....howtopic=103147

MP3 repacker

Reply #579 –
I nearly got down to 50 percent of original size on a track from this free download: http://grimtownmusic.com/2012/06/06/satanic-panic/

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:

https://github.com/ScottESanDiego/mp3packer

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: https://cdn.discordapp.com/attachments/1042536514783023124/1056003447205404682/mp3packer

Compiled from source code: https://github.com/ScottESanDiego/mp3packer

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:
mp3packer_aarch64_clang_static: https://files.catbox.moe/8ehjyw
mp3packer_x86-64_clang_static: https://files.catbox.moe/s8c9dq

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.