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

MP3 repacker

Reply #350
Quote
I think you may be misunderstanding exactly what mp3packer does. The main thing to realize is that it does not change quality at all; it only changes file size. If you want higher quality MP3 files, re-rip from the source. If you want slightly smaller MP3 files, that's what mp3packer is good at.


I understood the program function, I just don't made myself clear enough 

So then using repacker on my 320cbr files will produce smaller files without quality loss at all?
I was worried about the "depending on the LAME version used" described in the program functions.

Another question: if the original files are ripped with other enconder than LAME, repacking them using LAME will have any quality loss/problem ?

MP3 repacker

Reply #351
So then using repacker on my 320cbr files will produce smaller files without quality loss at all?
I was worried about the "depending on the LAME version used" described in the program functions.

Another question: if the original files are ripped with other enconder than LAME, repacking them using LAME will have any quality loss/problem ?


There will be no change in quality at all regardless of which encoder/settings had been used. The decoded output will be identical. The "depending on the LAME version" had to do only with how well a file repacks.

As for repacking, LAME has nothing to do with this. The repacking is done entirely by MP3 repacker and nothing else.

MP3 repacker

Reply #352
The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The strictly-enforce-iso switch in LAME will lower the maximum amount of data in one frame. However, mp3packer will either not change the amount of data in a frame (without -z), or it will lower it (with -z). This means that a file repacked with -z may have the issue fixed, but it's impossible to always fix it.


That sounds very interesting! mp3packer might "repair" the mp3 decoding issue by using the -z switch. What would be the percentage of "fixing" by using the -z switch? 50%, 90%, 99% ?? That would be interesting to know.

MP3 repacker

Reply #353
Just tried it again and my results

Black Sabbath (2002) Symptom Of The Universe (1970-78)

Using FhG MP3 Encoder 4.0.3 (dbpoweramp Reference) at 320kbps
Using High Quality setting.

Original: 29 files, 348.9 MB, 320.0 kbps
Result: 29 files, 301.0 MB, 275.4 kbps

Hmmm, almost 14% reduction...
this is results using Super-squeeze -z option which is quite slow ;( on a p3 800
with the default settings it actually added 1kb to all the files.

-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it. It is quite a bit safer than the old -z switch, but it increases the time to repack the files dramatically. On my computer, a 4-minute file which would get repacked in the blink of an eye would take around 30 seconds with this option enabled.

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?

I have a ton of CBR fhg files for I once used all the buggy Fhg encoders until 2005 when i discovered this place... I tried the result all over, in the car, portable, Hifi and headphones and no diff.

But again lovely proggie, keeps my ID tags and APEv2 with RG where applicable.
Do your ever wonder about your soul?
Can it be saved...

MP3 repacker

Reply #354
-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it.

(...)

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?


Two things:

1.) mp3packer is not lossy! mp3 files are encoded (by encoders) in a 2-pass process, first the audio data are lossily reduced and encoded and then in a second pass the result is being zipped (so to say).  The -z switch unzips the audio data (reverses the 2nd pass) but actually does not decode the audio data. Therefore it is actually indeed lossless. mp3packer then re-zips the audio data ( -z means "zipping") with somewhat more brute force methods so that the compression of the zipped mp3 file is finally higher. That's it.

2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.

Now, what is mp3packer doing: it strips off padding from 44.1 kHz mp3 files. As a consequence, any mp3surround info will be removed from the file by mp3packer, you will get a "normal" stereo file instead. Up to now it is not possible for mp3surround files "to survive" an mp3packer pass. So better you do not use mp3packer with mp3surround mp3 files.

MP3 repacker

Reply #355
thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z
Do your ever wonder about your soul?
Can it be saved...

MP3 repacker

Reply #356
thanks for the heads up, still what about mp3pro? anyone

make a backup copy of an mp3pro file, then use mp3packer with the file and after that try to play it with the mp3pro player. If it works, then (likely) okay, otherwise stop using mp3packer with mp3pro files.

Report the result here, please.

MP3 repacker

Reply #357
thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z

Doesn't using this program on MP3PRO files somewhat defeat it's purpose? MP3 Repacker removes padding, which is almost only available in real high bitrate MP3s. MP3PRO is aimed for very low bitrates, and should be struggling to deliver decent sound -> not pad.

MP3 repacker

Reply #358
The -z option should potentially provide savings at any bitrate.

MP3 repacker

Reply #359
Those are good ideas, but only the encoder can control either of them.

The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The good news is that if the input file does not suffer from either of these issues, the output file won't either.


thanks for your answer.

but there is something I do not understand.
lame developers said the bitrate increase at V0 in 3.98 version is because of the fhg fix.

I have made some tests on a track at V0 :
3.97 : 254 kbps
3.98 : 264 kbps

and I used mp3packer on those compressed tracks :
3.97 : 254 kbps
3.98 : 256 kbps

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?

MP3 repacker

Reply #360
so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?


No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.

MP3 repacker

Reply #361

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?


No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.


That's with default options...

I tried:

mp3packer -b 320 -R file.mp3

and that creates invalid files (also from LAME 3.98).
The author of this tool should read: http://www.hydrogenaudio.org/forums/index....showtopic=40308

MP3 repacker

Reply #362
2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.


thanks for the heads up, still what about mp3pro? anyone


I tried with mp3pro, no luck.
In both cases, with and without -z option the result files are smaller:

original :        4184422    100%
repacked :      3949402      94%
repacked,-z :  3863238      92%

However, in both cases the repacked file is not recognized as mp3pro anymore. It is played as mp3 at 22 kHz.
So, if mp3pro rely on some side information (as mentioned for the mp3surround), this info is apparently removed by the repacking.
~

MP3 repacker

Reply #363
Did a quick test with the -z flag, here are the results:

Original: 1424 MB
Packed: 1338 MB

Ratio: 94,0%

Some albums didn't compress at all (a few KB only), while others got 85% ratio  (15% off). While I couldn't find the pattern (encoder, stereo mode, genre), I greatly appreciate this tool.

Great work!!! 

The only thing missing (for now) would be dual-core support!

 

MP3 repacker

Reply #364
@Antonski:
Yeah. mp3packer will throw away mp3pro info. mp3pro is just mp3 with extra info added, and mp3packer only keeps the part that's actually mp3. The extra info is tagged as garbage and thrown out. I think I mentioned that somewhere earlier in the thread, but it's getting a bit long to read it all...
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #365
@Antonski:
Yeah. mp3packer will throw away mp3pro info. mp3pro is just mp3 with extra info added, and mp3packer only keeps the part that's actually mp3. The extra info is tagged as garbage and thrown out. I think I mentioned that somewhere earlier in the thread, but it's getting a bit long to read it all...


Though some "garbage" is thrown out, I appreciate the LYRICS tag (just started using them) not being discarded. So it only discards not useful metadata? Or has no influence in metadata whatsoever? Thanks!

MP3 repacker

Reply #366
I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.

MP3 repacker

Reply #367
I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.
APEv2 tags will be removed.

MP3 repacker

Reply #368
I'm getting very small reduction, almost every frame remains 320

Am I doing something wrong? I'm using "mp3repacker -z"

From 98 mb -> 96 mb from one CD

From 55 mb -> 54 mb from another one

MP3 repacker

Reply #369
that's normal. i guess that the mp3(s) were encodec VERY well.

MP3 repacker

Reply #370
In the manual you say about the debug option:
Quote
It is recommended that you redirect the output to a file, as the information gets quite verbose.


How can this be done? Have I missed the explanation somewhere?

Roger

MP3 repacker

Reply #371
In the manual you say about the debug option:
Quote

It is recommended that you redirect the output to a file, as the information gets quite verbose.


How can this be done? Have I missed the explanation somewhere?

Roger


To redirect stdout to a file, you add ">filename.ext" to your commandline. So in this case, you might write
Code: [Select]
mp3packer --debug "all" test.mp3 >debug.txt


Edit: Be careful with this, it can produce text files in the hundreds of megabytes. At least, it did this in my little test just now.

MP3 repacker

Reply #372
Hi!
I have a request:
It would be nice if mp3repacker would print the time on Sync errors in addition to the frame number. Then I could easily find that position with my mp3 player and look how the error sounds.

Ciao!

MP3 repacker

Reply #373
Sorry if it was discussed already, but the topic is already too long.

I run mp3recpacker on 2932 files, and it came up bigger! how can that be?

2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).

0.0 % decrease in size.

0 items failed.

PS: i used -s -t as parameters, and runned it from WinMP3Packer.

MP3 repacker

Reply #374
2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).


From the numbers, it looks like a signed int is used for the number of bytes, which overflowed (possibly more than once, considering the number of files). So it's just a display error, the files actually became ~100MiB smaller in the process if that interpretation is correct.