I remember this old old thread i visited about a tool that "losslessly" reduces mp3 vbr files but i cant find where it is now.
need help.
Thanks in advance.
sorry if wrong thread/forum
Sounds like you're thinking of MP3 Repacker:
http://www.hydrogenaudio.org/forums/index....showtopic=32379
http://www.hydrogenaudio.org/forums/index....showtopic=32379
You are probably talking about mp3repacker and it doesn't reduce the size of VBR files, but CBR files. VBR files are already optimized as much as they can, while CBR files can contain less samples in a frame than nessesary (if I understood it correctly).
Buy a larger harddrive
They don't cost so much anymore...
Also from my own experience with mp3-repacker, is that it doesn't really gain much space.
Buy a larger harddrive
They don't cost so much anymore...Also from my own experience with mp3-repacker, is that it doesn't really gain much space.
You might be thinking of mp3repacker. What this program actually does is "converts" CBR files to VBR files by excising the unused bits in each frame (or vice-versa, by padding each frame to the target constant bitrate).
Edit: And a shade too slow...
Edit: And a shade too slow...
thanks for the fast reply.
i'll look into it.
i'll look into it.
Hi, have anyone tested MP3 Repacker and gained any positive results ? Does it actually reduce CBR MP3 files and if it does, then by how many percents in average ??? 5-10 % or less ???
p.s. Advice for the topicstarter - use mp3DirectCut to remove silence and even unwanted parts of music (parts that you don't like) from your MP3 files without re-encoding them.
If you are familiar with "visual" sound editing in such editors as Sound Forge or Adobe Audition, if you can detect the beginnings and endings of bars\loops by looking at the waveform - then you can even make your own edits\mixes of your tracks without having to re-encode them and loosing quality.
p.s. Advice for the topicstarter - use mp3DirectCut to remove silence and even unwanted parts of music (parts that you don't like) from your MP3 files without re-encoding them.
If you are familiar with "visual" sound editing in such editors as Sound Forge or Adobe Audition, if you can detect the beginnings and endings of bars\loops by looking at the waveform - then you can even make your own edits\mixes of your tracks without having to re-encode them and loosing quality.
QUOTE (deranger @ Oct 20 2009, 00:33) 
Hi, have anyone tested MP3 Repacker and gained any positive results ? Does it actually reduce CBR MP3 files and if it does, then by how many percents in average ??? 5-10 % or less ???
It works fine, but as I said, don't get your expectations too high. I don't remember my results, but I was really disappointed. I think the gain was approx 1%, maybe even less. Could be because I have used a more recent LAME to create them with maybe. AFAIR later LAME releases optimizes the CBR bits better.
No, really buy a larger harddrive...
QUOTE (deranger @ Oct 20 2009, 00:33)
p.s. Advice for the topicstarter - use mp3DirectCut to remove silence and even unwanted parts of music (parts that you don't like) from your MP3 files without re-encoding them.
Using mpTrim, you can automate batch processing of this (yes, it's lossless)
MP3 Repacker:
219 items 320 kbps > 292 kbps [8.8%]
26 items 256 kbps > 244 kbps [4.7%]
13 items 224 kbps > 217 kbps [3.1%]
Obviously diminishing returns, and overall like odyssey said, not a huge saving. Also for some music there's hardly any gain, but for other types you can make a big saving:
320 kbps > 237 kbps [a 1961 stereo live jazz recording]
So it can be worth it.
C.
EDIT: clarity and added %
219 items 320 kbps > 292 kbps [8.8%]
26 items 256 kbps > 244 kbps [4.7%]
13 items 224 kbps > 217 kbps [3.1%]
Obviously diminishing returns, and overall like odyssey said, not a huge saving. Also for some music there's hardly any gain, but for other types you can make a big saving:
320 kbps > 237 kbps [a 1961 stereo live jazz recording]
So it can be worth it.
C.
EDIT: clarity and added %
QUOTE (deranger @ Oct 20 2009, 00:33)
p.s. Advice for the topicstarter - use mp3DirectCut to remove silence and even unwanted parts of music (parts that you don't like) from your MP3 files without re-encoding them.
BTW, note that if you choose to mp3repack your files, removing silence does not really gain anything worthy. For digital silence it will just allocate 0kbit for a frame... Maybe the frame itself uses something, but probably only a few bits.
Aww, now you made me want to mp3repack my entire collection just to see the gain
I'll be back with numbers for ~5000 files. The manual also got me curious how much -z switch could gain.
I'm processing 4917 files.
Original size incl. loads of tags: 30.110.350.822 bytes
Size after removing any tags (using foobar2000) to show true gain from mp3repacker: 30.101.122.775 bytes
First run was with default settings of mp3repacker:
Size: 29.827.544.257 bytes
Processing time: 31 mins.
Notice how close to my claim of just 1% gain
Second run with -z -t -s switch:
(Currently running, I'll post later when it finishes.) Edit: Umm, this will take approx 1,5 day
Edit 2: It seems (from the first comparisons) that this will gain an additional 1,5% - That's ~2,5% gain over original files. Well it's space, but it's not overwhelming.
I may try a third run to see the gain from -t -s switches only (various tags not detected by foobar2000).
carpman: Which encoder was used for these files. I'm surprised you can gain so much on yours and I can't barely do anything on mine...
Original size incl. loads of tags: 30.110.350.822 bytes
Size after removing any tags (using foobar2000) to show true gain from mp3repacker: 30.101.122.775 bytes
First run was with default settings of mp3repacker:
Size: 29.827.544.257 bytes
Processing time: 31 mins.
Notice how close to my claim of just 1% gain
Second run with -z -t -s switch:
(Currently running, I'll post later when it finishes.) Edit: Umm, this will take approx 1,5 day
Edit 2: It seems (from the first comparisons) that this will gain an additional 1,5% - That's ~2,5% gain over original files. Well it's space, but it's not overwhelming.
I may try a third run to see the gain from -t -s switches only (various tags not detected by foobar2000).
carpman: Which encoder was used for these files. I'm surprised you can gain so much on yours and I can't barely do anything on mine...
QUOTE (odyssey)
I'm surprised you can gain so much on yours and I can't barely do anything on mine...
Try FhG encoder (from http://www.all4mp3.com ) or lame 3.98 at 320 kbps.
lvqcl answered it for me.
C.
C.
QUOTE (odyssey @ Oct 20 2009, 10:40)
For digital silence it will just allocate 0kbit for a frame...
Just a correction: The smallest frame with MPEG 1 layer 3 ( 32/44/48Khz ) is 32kbps. Digital silence uses this.
As has been discussed above, MP3Packer's greatest value is on 320 kbps CBR files.
In my experience, 320kbps CBR files compress to about 85% using MP3Packer. I have compressed 170 such files and the average bitrate, post-compression, is 270kbps.
Mp3 encoders that make better use of a bit reservoir will compress less. Most mp3's encoded with LAME's modern settings (even CBR) will not shrink more than 0.1% using MP3Packer.
Best candidates for compression are WMP and iTunes encodes (both based on the Fgh encoder, I think).
In my experience, 320kbps CBR files compress to about 85% using MP3Packer. I have compressed 170 such files and the average bitrate, post-compression, is 270kbps.
Mp3 encoders that make better use of a bit reservoir will compress less. Most mp3's encoded with LAME's modern settings (even CBR) will not shrink more than 0.1% using MP3Packer.
Best candidates for compression are WMP and iTunes encodes (both based on the Fgh encoder, I think).
Thanks for posting your results. Very interesting 
p.s. Have anyone tried MP3 Repacker on VBR files ? The author of the topic asked if he could compress his VBR files.
It will be amusing if MP3 Repacker gives any noticeable gain on VBR mp3 files -) This will mean that the encoder the files were created with makes really poor usage of both bit reservoir and VBR technique
p.s. Have anyone tried MP3 Repacker on VBR files ?
The author of the topic asked if he could compress his VBR files. It will be amusing if MP3 Repacker gives any noticeable gain on VBR mp3 files -) This will mean that the encoder the files were created with makes really poor usage of both bit reservoir and VBR technique
I've gotten some very slight gains trying MP3Packer on (non-LAME) VBR files.
However, the vast majority of VBR mp3 files out there are encoded by LAME; most other common mp3 encoders are mainly used in CBR mode.
So, unless the OP is sitting on a bunch of non-LAME VBR files, he stands to gain nothing by using MP3Packer.
However, the vast majority of VBR mp3 files out there are encoded by LAME; most other common mp3 encoders are mainly used in CBR mode.
So, unless the OP is sitting on a bunch of non-LAME VBR files, he stands to gain nothing by using MP3Packer.
My experience is consistent with what's stated above - that mp3packer is most effective with CBR 320 mp3s. I've found that although results do vary, I can expect it to shave off 40kbps on average.
For example, I have 5 former 320kbps albums which I repacked, and 3 ended up at 280kbps, while one averaged 276 and another 282. At 280kbps, that's a 12.5% improvement.
Fortunately, 320kbps mp3s aren't incredibly common anymore. However, if you come across them online - ahem, that is, if you discover old 320kbps rips for which you no longer have the source, repacking is a nice way to save space.
For example, I have 5 former 320kbps albums which I repacked, and 3 ended up at 280kbps, while one averaged 276 and another 282. At 280kbps, that's a 12.5% improvement.
Fortunately, 320kbps mp3s aren't incredibly common anymore. However, if you come across them online - ahem, that is, if you discover old 320kbps rips for which you no longer have the source, repacking is a nice way to save space.
QUOTE ([JAZ] @ Oct 20 2009, 21:10)
QUOTE (odyssey @ Oct 20 2009, 10:40)
For digital silence it will just allocate 0kbit for a frame...
Just a correction: The smallest frame with MPEG 1 layer 3 ( 32/44/48Khz ) is 32kbps. Digital silence uses this.
You are probably right. However, the manual made me believe it was 0:
QUOTE
-b #
Minimum bitrate allowed for output. Defaults to 0, which means all frame sizes are allowed. If the number given is a valid bitrate, the minimum frame size will be "dithered" between padded and unpadded frames, depending on standard CBR rules. If the bitrate given is one more than a valid bitrate, all frames will be padded. Anything larger than the maximum bitrate will be clamped to a padded maximum-bitrate frame. All other bitrates will round up to the next higher unpadded frame.
For example, -b 129 will result in the smallest allowed frame size being a padded 128kbps frame. -b 117 will result in the smallest allowed frame size being an unpadded 128kbps frame. If -b 128 is used with 44100Hz files, the minimum bitrate will depend on the frame number. Assuming 44100Hz, for 2 frames out of 49 the minimum frame will be unpadded, for the other 47 it will be padded. All bitrates from 114 to 127 will result in the smallest frame being an unpadded 128kbps frame.
Minimum bitrate allowed for output. Defaults to 0, which means all frame sizes are allowed. If the number given is a valid bitrate, the minimum frame size will be "dithered" between padded and unpadded frames, depending on standard CBR rules. If the bitrate given is one more than a valid bitrate, all frames will be padded. Anything larger than the maximum bitrate will be clamped to a padded maximum-bitrate frame. All other bitrates will round up to the next higher unpadded frame.
For example, -b 129 will result in the smallest allowed frame size being a padded 128kbps frame. -b 117 will result in the smallest allowed frame size being an unpadded 128kbps frame. If -b 128 is used with 44100Hz files, the minimum bitrate will depend on the frame number. Assuming 44100Hz, for 2 frames out of 49 the minimum frame will be unpadded, for the other 47 it will be padded. All bitrates from 114 to 127 will result in the smallest frame being an unpadded 128kbps frame.
QUOTE (odyssey @ Oct 20 2009, 12:51)
I'm processing 4917 files.
Original size incl. loads of tags: 30.110.350.822 bytes
Size after removing any tags (using foobar2000) to show true gain from mp3repacker: 30.101.122.775 bytes
First run was with default settings of mp3repacker:
Size: 29.827.544.257 bytes
Processing time: 31 mins.
Original size incl. loads of tags: 30.110.350.822 bytes
Size after removing any tags (using foobar2000) to show true gain from mp3repacker: 30.101.122.775 bytes
First run was with default settings of mp3repacker:
Size: 29.827.544.257 bytes
Processing time: 31 mins.
Second run with -z -t -s switch:
29.294.671.973 bytes
Processing time: 34 hours, 45 mins.
Gain from default switches: 1,79%
Gain from with source: 2,71%
All files are CBR in this case.
QUOTE (odyssey @ Oct 22 2009, 10:29)
You are probably right. However, the manual made me believe it was 0:
QUOTE
-b #
Minimum bitrate allowed for output. Defaults to 0, which means all frame sizes are allowed.
Minimum bitrate allowed for output. Defaults to 0, which means all frame sizes are allowed.
I see where your confusion comes from then. The size of a frame cannot be zero, but the parameter, when used with VBR is allowed to be zero to say no lower limit.
By the way... LAME 3.98 (compared to 3.97) has the following code in reservoir.c:
If I understand the code correctly, that's why files encoded to 320 kbps with lame 3.98 can be compressed (to ~300...310 kbps) by mp3repacker.
Does it mean that mp3repacker can break this compatibility with some old FhG decoders ?
CODE
/*
if (gfp->strict_ISO == old_FhG_decoder)
always enabled because of compatibility problems with some old FhG decoders
which is distributed with almost every Windows Installation
*/
maxmp3buf = 8 * ((int) (320000 / (gfp->out_samplerate / (FLOAT) 1152) / 8 + .5));
if (gfp->strict_ISO == old_FhG_decoder)
always enabled because of compatibility problems with some old FhG decoders
which is distributed with almost every Windows Installation
*/
maxmp3buf = 8 * ((int) (320000 / (gfp->out_samplerate / (FLOAT) 1152) / 8 + .5));
If I understand the code correctly, that's why files encoded to 320 kbps with lame 3.98 can be compressed (to ~300...310 kbps) by mp3repacker.
Does it mean that mp3repacker can break this compatibility with some old FhG decoders ?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.