Wed 05 Sep 2012 03:39:03 AM UTC, comment #1:
I see what you're saying, but I don't think this is worth doing.
When we say we want to use the bitrate of the input file, we're really talking about reproducing the conditions under which the original mp3 was encoded. In general (e.g. for a VBR-encoded mp3 or an ogg vorbis file), the bitrate doesn't tell us that, and we're just creating an output file that happens to have the same size but is not necessarily encoded like the original. There are some heuristics we could use, rummaging around for id3 and lame tags and the like, but in general we can't make the output encoded like the input.
And even if we could, data is lost regardless, since we're doing a lossy re-encoding. If someone uses normalize-mp3 expecting not to lose data, they're doing the wrong thing. Possibly that could be made more clear somehow, and that people who really care about the exact encoding options used by normalize-mp3 should modify the script.
I guess I should say that I never use normalize-mp3 myself. It always seemed like kind of a bad idea, but years ago I got a lot of requests to help automate the decode-normalize-reencode process, so I threw it together. It's caused some confusion, and I'm somewhat inclined to remove it in future versions.
All of which is not to say that I wouldn't accept patches to it, but I'm unlikely to find time to hack on normalize-mp3 further myself.
By the way, thank you for your work as debian maintainer. I've been a loyal debian fan since I converted from slackware way back when :-)
|