I don't know the best way to quickly describe this in a subject line, but mp3packer appears to only recognize 96kbps and 128kbps as valid "CBR destinations."
If I take a CBR file and process it to VBR with mp3packer, and then process the resulting VBR file back to CBR, it will typically end up at the same bitrate as the initial CBR file.
For example, a 192kbps CBR file may condense down to an average VBR bitrate of 187kbps. And when I process that 187kbps file back to CBR, it ends up as a 192kbps file again. This pattern holds with initially-CBR files at all bitrates except for 112kbps.
If I take a 112kbps CBR file and process it to VBR through mp3packer, and then run the resulting VBR file back to CBR, it ends up as 128kbps CBR. This is a consistent pattern across computers (all Windows) and all originally-112kbps CBR files.
Does anyone know why it happens this way? Is there something atypical about a 112kbps frame that isn't true of other mp3 frames? Or is it simply a programming overlook in mp3packer? (or some other explanation)
perhaps a simpler way to explain this:
When converting an mp3 file with max frame size of 112kbps, to CBR, mp3packer will nevertheless convert the file to 128kbps instead of 112kbps. It even works with files that start out as 112kbps CBR: if I process them to VBR, and then back to CBR, the resulting CBR file is 128kbps. It seems that 112kbps is "skipped over" amongst CBR options; I haven't noticed this happening for any other mp3 bitrate.
This happens with older versions of mp3packer, and also with 2.04.
I just web-searched about this, and the only thing I came across was my post from three years ago. So I suppose this is a bump.
isn't mp3packer abandoned software?
isn't mp3packer abandoned software?
Maybe so. I hadn't seen that it was abandoned, but there hasn't been a new version since fall 2012.
The program is open source. Even if it's not actively developed you could look at the code if you're really interested.
may be open source but buggy as hell. it needs massive cleaning up in order to build. especially on linux. actually i think it was written with mingw in mind.
may be open source but buggy as hell. it needs massive cleaning up in order to build. especially on linux. actually i think it was written with mingw in mind.
How do you get to the idea that mp3packer is buggy?
As for the OP: do you have any hint that mp3packer dosn't use 112 kbps frames?
The mere fact that going from CBR112 to VBR, back to CBR which results in CBR128 doesn't prove that. Repackaging twice can loose efficiency. It's great that it doesn't happen at higher bitrates.
as compiled it's probably fine. but if i try to build it i get wrong results.
as compiled it's probably fine. but if i try to build it i get wrong results.
What I hear is: "When somebody else does it it works fine but when I do it its doesn't.. must be the software" :D
Mp3packer is a standard tool i use for all mp3 encoding and it hasn't failed on me yet. but as you said I don't deal with the sourcode just the precompiled version.