If there is a tool to optimize huffman table of ogg files (rehuff.exe) does this mean that another tool for MP3 (or any other format that uses huffman tables.. like jpg,..) could be implemented (as MP3 uses huffman too)..

yes it could be - there even was a thread about it (about rehuff and etc.) - but as stated by IIRC Frank Klemm the possible bitrate gain would be ~0.1% so I don't think it'd be usablel

OK i agree. But it would reduce size (rather than making better bitrate..). It is useless for a few mp3 but what about (20GIGA of mp3's) is it worth it..? i think yes.. and what about jpeg or other huffmanized formats..

i think this should be done .. like 7-zip author did.. he provided better zip compression this resulted into:

01- smaller zip files (based upon zlib)
02- smaller png files (it uses zlib)
03- smaller mng files (it also uses zlib)

so if any format uses zlib, Igor's (7-zip author) work will be handy.. so it would revive it a bit..

so in result i would recommend making a tool for mp3 and lets call it a lossless optimizer as it would reduce file size without hurting quality..

i found some info about the huffman tables.. and i'm reading them..

BTW: can you provide me a link to FRANKS reponse..

http://sourceforge.net/projects/recomp3/

IIRC the huffman table for JPEG is fixed and cannot be changed. Rehuff only works if the table can be changed. Even if MP3 have the tables, you might not be able to get much out of it since MP3 is not true VBR and huffman would only work if you can bring the size of one frame size down to the size below and looking at the MP3 frame sizes 8 16 24 32 48 64 80 96 112 128 160 192 224 256 320 and considering that rehuffing usually gives around at most 5% decrease, I don't think that's going to help.

tangent wrote:

how do you come to such a conclusion? only because mp3 uses fix sized bins for packaging the frames? what about storing a true vbr file on your hard disk with a file system using 2048 bytes sectors, wouldn't that disqualify as true vbr in your definition too?

It's empty... what did you mean with this link?

Yup.


Nope.

It's a ReHuff project for MP3 (that will probably include some sort of simple "bitrate peeling") that Tominaga san is working on.

But, according to him, it's on it's initial stages, and other projects have higher priority, so it will probably take a long time to get near an usable state.

And, according to him too, files encoded by latest Lame versions won't be "optimizable" anyway, since the optimizing routines are already included in Lame.

I don't understand you. Could you explain to me your definition of *true vbr* then? A formal definition would be nice.

tangent is right about the fact that for MP3 the huffman tables are fixed. encoder and decoder use that fixed set of tables. if you would define a mp3 like format which would allow to transmit the used tables to the decoder, then it would be possible to optimize the huffman codes for a given song. a 5 percent reduction for every frame would result in an 5 percent smaller vbr mp3 file, given that your files aren't very small.

I will not explain it to you because it is obvious to me that you only have the intention to nitpick on it and I shall not waste my time with your request.

Sorry, but I have no spare time to release the very first version of recomp3. If it released, it will be the bitrate-peerer of mp3.