Peoples,
I'm about to launch into a debugging session to see why mp3gain (http://mp3gain.sourceforge.net/ ) and madplay 0.15.1b don't seem to be playing together (no pun intended). I thought I'd ask if anyone has used the two together yet, or if there is another linux-based replaygain processor (for adding replaygain to existing mp3s) that is more reliable.
map3gain does appear to be adding a tag, as it finds it again if rerun over the same file.
"# mp3gain /tmp/Abracadabra.mp3 /tmp/Abracadabra.mp3 Recommended "Track" dB change: -1.690000 Recommended "Track" mp3 gain change: -1 Max PCM sample at current gain: 28533.063680 Max mp3 global gain field: 180 Min mp3 global gain field: 116
Recommended "Album" dB change for all files: -7.490000 Recommended "Album" mp3 gain change for all files: -5"
madplay doesn't appear to find it:
"# madplay -G -Tv /tmp/Abracadabra.mp3 MPEG Audio Decoder 0.15.1 (beta) - Copyright (C) 2000-2004 Robert Leslie et al. Title: Abracadabra Artist: The Steve Miller Band Album: Golds Greatest Hits Track: 11 Year: 1982 Genre: Vocal Encoder Version: LAME 3.92 VBR Method: constant Bitrate: 255+ kbps Stereo Mode: normal Preset: none Unwise Settings: no Encoding Flags: Lowpass Filter: 19500 Hz ATH Type: 2 Noise Shaping: 1 Surround: none Start Delay: 576 samples End Padding: 1503 samples Source Rate: 44.1 kHz Music Length: 9948263 bytes Audio Frames: 11900" (note the missing "Replay Gain" printout I expect after reading the source)
I'd hasten to add that I suspect mp3gain of doing something wrong, not madplay. I'm guessing the tag is wrong or in the wrong place.
Any info would be appreciated, otherwise I'll report my findings to the list when I discover the root cause.
/Bruce
On Mar 31, 2004, at 12:01 AM, Bruce Fitzsimons wrote:
I'm about to launch into a debugging session to see why mp3gain (http://mp3gain.sourceforge.net/ ) and madplay 0.15.1b don't seem to be playing together (no pun intended). I thought I'd ask if anyone has used the two together yet, or if there is another linux-based replaygain processor (for adding replaygain to existing mp3s) that is more reliable.
map3gain does appear to be adding a tag, as it finds it again if rerun over the same file.
From my brief look at the mp3gain code I couldn't find evidence that it is actually writing a Replay Gain tag. It appears instead to be modifying the global_gain field of each Layer III frame. This modification should work with all players with or without Replay Gain support, though there may not be any indication of it.
What's a good heuristic for determining whether a file is a valid MP3 or not?
My first thought was to grab a chunk at the beginning of the file and repeatedly call mad_header_decode until it comes back with a header and take that as an indication that the file is valid.
However, on trying this out on the first 10k of a plain text file, mad_header_decode still returns a header found at 8k but with wrong data in it. Maybe this is due to it just looking for the sync bits and this file happened to have them within its first 10k?
Is there a better way of doing this? Maybe start trying to decode and if more errors than a certain threshold occur, assume the file is not valid?
Thanks, Erik
On Thu, Apr 01, 2004 at 02:00:44PM +0100, Erik Jälevik wrote:
What's a good heuristic for determining whether a file is a valid MP3 or not?
My first thought was to grab a chunk at the beginning of the file and repeatedly call mad_header_decode until it comes back with a header and take that as an indication that the file is valid.
However, on trying this out on the first 10k of a plain text file, mad_header_decode still returns a header found at 8k but with wrong data in it. Maybe this is due to it just looking for the sync bits and this file happened to have them within its first 10k?
Is there a better way of doing this? Maybe start trying to decode and if more errors than a certain threshold occur, assume the file is not valid?
I read up to 25000 (arbitrary) bytes of data. Fatal errors are fatal; the only errors I handle are MAD_ERROR_LOSTSYNC, MAD_ERROR_BADCRC (which I don't have a test case for), and MAD_ERROR_BUFLEN/MAD_ERROR_BUFPTR.
More specifically, I count the number of bytes read in a given pass; if more than the threshold is read without getting a good packet, I bail. (I also explicitly subtract things like Xing and ID3 headers from this count; ID3v2 headers can easily be larger than that.)
The primary case where this matters is WAVs with MP3 data in them, and unknown headers. This handles those fine (though why people are putting MP3 data in WAVs is well beyond my comprehension).
My actual code is at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmania/stepmania/src/Rag...
See RageSoundReader_MP3::do_mad_frame_decode.
(Any comments on the way I'm doing this are appreciated. I havn't received any bug reports due to mis-detected files in quite a while.)
Thanks, Glenn.
I'll have a look at your code.
Erik
----- Original Message ----- From: "Glenn Maynard" g_mad@zewt.org To: mad-dev@lists.mars.org Sent: Thursday, April 01, 2004 9:58 PM Subject: Re: [mad-dev] Heuristic for determining valid MP3 file
On Thu, Apr 01, 2004 at 02:00:44PM +0100, Erik Jälevik wrote:
What's a good heuristic for determining whether a file is a valid MP3 or
not?
My first thought was to grab a chunk at the beginning of the file and
repeatedly
call mad_header_decode until it comes back with a header and take that as an indication that the file is valid.
However, on trying this out on the first 10k of a plain text file, mad_header_decode still returns a header found at 8k but with wrong data in
it.
Maybe this is due to it just looking for the sync bits and this file
happened to
have them within its first 10k?
Is there a better way of doing this? Maybe start trying to decode and if
more
errors than a certain threshold occur, assume the file is not valid?
I read up to 25000 (arbitrary) bytes of data. Fatal errors are fatal; the only errors I handle are MAD_ERROR_LOSTSYNC, MAD_ERROR_BADCRC (which I don't have a test case for), and MAD_ERROR_BUFLEN/MAD_ERROR_BUFPTR.
More specifically, I count the number of bytes read in a given pass; if more than the threshold is read without getting a good packet, I bail. (I also explicitly subtract things like Xing and ID3 headers from this count; ID3v2 headers can easily be larger than that.)
The primary case where this matters is WAVs with MP3 data in them, and unknown headers. This handles those fine (though why people are putting MP3 data in WAVs is well beyond my comprehension).
My actual code is at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmania/stepmania/src/Rag...
See RageSoundReader_MP3::do_mad_frame_decode.
(Any comments on the way I'm doing this are appreciated. I havn't received any bug reports due to mis-detected files in quite a while.)
-- Glenn Maynard
Rob Leslie wrote:
On Mar 31, 2004, at 12:01 AM, Bruce Fitzsimons wrote:
I'm about to launch into a debugging session to see why mp3gain (http://mp3gain.sourceforge.net/ ) and madplay 0.15.1b don't seem to be playing together (no pun intended). I thought I'd ask if anyone has used the two together yet, or if there is another linux-based replaygain processor (for adding replaygain to existing mp3s) that is more reliable.
map3gain does appear to be adding a tag, as it finds it again if rerun over the same file.
From my brief look at the mp3gain code I couldn't find evidence that it is actually writing a Replay Gain tag. It appears instead to be modifying the global_gain field of each Layer III frame. This modification should work with all players with or without Replay Gain support, though there may not be any indication of it.
Thanks Rob.
I see the trick. It's linked off replaygain.org, and uses the *algorithm*, but doesn't write the standard replaygain mp3 tags. It *does* write some custom tags in the APE standard though.
I'll see what improvements I can come up with.
/Bruce
Bruce Fitzsimons wrote:
Rob Leslie wrote:
On Mar 31, 2004, at 12:01 AM, Bruce Fitzsimons wrote:
I'm about to launch into a debugging session to see why mp3gain (http://mp3gain.sourceforge.net/ ) and madplay 0.15.1b don't seem to be playing together (no pun intended). I thought I'd ask if anyone has used the two together yet, or if there is another linux-based replaygain processor (for adding replaygain to existing mp3s) that is more reliable.
map3gain does appear to be adding a tag, as it finds it again if rerun over the same file.
I'll see what improvements I can come up with.
I've put together a quick test based off minimad and the gain_analysis.[ch] from the mp3gain source. Although it uses a Pink Noise 64.82 dB value (I think) rather than the mandated 83 dB. Sigh.
I will turn it into a command line tool, is there any interest in such a thing? Any better suggestions for the replaygain algo (the math looked a bit daunting)?
Out of interest Rob, do you know why I would have had to multiply the libmad output by 2^15 (after mad_f_todouble) to make it equivalent to the (slightly hacked) lame output?
/Bruce
On Apr 5, 2004, at 4:01 AM, Bruce Fitzsimons wrote:
Out of interest Rob, do you know why I would have had to multiply the libmad output by 2^15 (after mad_f_todouble) to make it equivalent to the (slightly hacked) lame output?
Probably because libmad returns samples between -1 and +1; to convert this to signed 16-bit samples requires multiplication by 2^15. This is essentially what minimad's scale() does, with additional rounding and clipping, and without first converting to floating-point double.
On Fri, 2004-04-02 at 10:57, Bruce Fitzsimons wrote:
I see the trick. It's linked off replaygain.org, and uses the *algorithm*, but doesn't write the standard replaygain mp3 tags. It *does* write some custom tags in the APE standard though.
I'll see what improvements I can come up with.
I've only come across this message today. The replaygain.org site hasn't been updated for years, it's very misleading..
the 83dB reference, the kind of tag to use.. have never reached much of real use. By the time replaygain really was implemented into tools, the de-facto standard evolved into :
1/ APEv2 tags, put at the end of file, easy to parse. Those are key=value kind of tag, for the replaygain keys (case-insentive) it gives something like : replaygain_track_gain=-4.36 dB replaygain_track_peak=1.042839 replaygain_album_gain=-5.19 dB replaygain_album_peak=1.085183 The only replyagain aware tools I came across (mp3gain, foobar, and also the musepack xmms plugin for mpc files) use those tags.
2/ "89dB reference level" instead of the SMPTE-200 _83dB SPL_ calibrated reference. that's better suited to POP music levels (since under the original reference, all POP files' gain were below -6dB, and by large). Note that the name "89dB reference" is rather misleading, unless you consider 89dB to be an abstract value, the "expected loudness obtained by playing on an SMPTE-200 calibrated system" for the music you expect to be playing.
The whole point is : we don't expect the user to actually *listen* to it at 89dBSPL (much too loud !). in fact it is still assumed he will listen to it at 83dB. (i.e., we assume the sound system amplifies 6dB less than a SMPTE-200 calibrated. -> we assume some kind of 77dB-calibrated sound-sytem) The value 83+6="89dB" is purely virtual. The new standard's reference's physical basis is in fact : it assumes a 77dBSPL (=83-6) calibrated sound-system.
Recent projects planning to support replaygain will likely be using those de-facto standards, since these are the only ones currently in use. For instance, the C++ TagLib library is currently adding "APE tags in mp3" support. And then will read replaygain tags from those tags as well as the other mentionned tags.
IMO working on modifications for mp3gain to support other tags, or any other work aiming at better conformance with the outdated replaygain.org specs is somewhat a waste of time..
-
Bruce Fitzsimons -
Erik Jälevik -
Glenn Maynard -
Rob Leslie -
Samuel Krempp