Skip to main content

Topic: MP3 repacker (Read 465450 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • rbrito
  • [*][*]
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: 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.

  • dj lists
  • [*]
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.
  • Last Edit: 14 August, 2013, 05:16:55 AM by dj lists

  • ScottE
  • [*]
MP3 repacker
Reply #577
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. :-)

  • goa pride
  • [*][*]
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
Lame 3100a [32bit and 64bit]                          https://bit.ly/1VPTGbO
WinMP3Packer all-in-one [32bit and 64bit]     https://bit.ly/1PAtMS1
MP3Suite.bat customizable [64bit encoders]   http://bit.ly/2bLIU77

  • Porcus
  • [*][*][*][*][*]
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?

  • [JAZ]
  • [*][*][*][*][*]
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.

  • robert
  • [*][*][*][*][*]
  • Developer
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.

  • [JAZ]
  • [*][*][*][*][*]
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.

  • Porcus
  • [*][*][*][*][*]
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.
  • Last Edit: 25 January, 2014, 11:16:29 AM by Porcus

  • [JAZ]
  • [*][*][*][*][*]
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.
  • Last Edit: 25 January, 2014, 01:33:16 PM by [JAZ]

  • Porcus
  • [*][*][*][*][*]
MP3 repacker
Reply #585
D is going to sound like B*


Thanks. 

Obviously, allowing the user to do what the user asks, is far from fool-proof :-)

  • Porcus
  • [*][*][*][*][*]
MP3 repacker
Reply #586
Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571
http://www.hydrogenaudio.org/forums/index....showtopic=99206

MP3 repacker
Reply #587
Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571
http://www.hydrogenaudio.org/forums/index....showtopic=99206

Good idea

  • hidn
  • [*][*]
MP3 repacker
Reply #588
"Must Have" tool for sets. Big Thank You for Great Work.

  • Jaff2002
  • [*]
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.
  • Last Edit: 16 July, 2014, 10:11:23 PM by Jaff2002