Easy instant switching between both would help a lot.
Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.
Originator code[blockquote]000 = Replay Gain unspecified 001 = Replay Gain pre-set by artist/producer/mastering engineer 010 = Replay Gain set by user 011 = Replay Gain determined automatically, as described in Calculating (above)other = reserved for future use[/blockquote]For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is 000 (Replay Gain unspecified), then the player should ignore that Replay Gain adjustment field. For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is unknown, then the player should still use the information within that Replay Gain Adjustment field. This is because, even if we are unsure as to how the adjustment was determined, any valid Replay Gain adjustment is more useful than none at all.
Quote from: Fandango on 13 January, 2011, 12:22:57 PMWell, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.Have a look at the reference in post #94; further evidence that BS.1770 does a slightly better job than ReplayGain. R128 is based on and a further improvement to BS.1770.In addition to strong acceptance in Europe, BS.1770 is specifically called out in the CALM act here in the US. The FCC is required to evaluate and, in 1 years time, require broadcasters to deploy it. It is possible the technology will be further improved in this process.
Why not implement benski's suggestion?
QuoteWhy not implement benski's suggestion?For example because we don't want to waste bits in the file. Wait... so which player / file format actually implements David's original gain data format proposal (16-bit field per gain value)?Chris
I see. So what's the de-facto standard (most widely used) bit stream format? The one that foobar uses, i.e. clear-text? i.e. around 70 characters = 560 bits to store two gains and a peak value? I'm speechless.
Quote from: Fandango on 13 January, 2011, 12:22:57 PMEasy instant switching between both would help a lot.This would be first and foremost a player feature. Are you planning to implement it?
I think it might be worth doing something likeREPLAYGAIN_ALGORITHM=ReplayGain 1.0orREPLAYGAIN_ALGORITHM=EBU R128so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done
Certainly I'm in favor with benski's proposal:Quote from: benski on 13 January, 2011, 01:52:56 PMI think it might be worth doing something likeREPLAYGAIN_ALGORITHM=ReplayGain 1.0orREPLAYGAIN_ALGORITHM=EBU R128so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be doneIn the meantime a player may try to make a guess based on units dB vs. LU.
That's completely wrong!
So if the old tags are used, how do I know whether audio files have been processed with r128gain or another EBU R128 implementation? The REPLAYGAIN_REFERENCE_LOUDNESS tag field? What if a Replay Gain scanner does not remove this tag field when I change from EBU R128 to Replay Gain?
Personally I'd like to be able to switch between both in an instant in order to compare their capabilities even more so because their coexistence in the PC audio domain has just started with this project, I thought that's obvious. Currently I would have to prepare two sets of audio files in order to compare them adequately, not very practical if you don't really know what music you actually need to test, as I don't remember every album where I found something odd.
$ r128gain ../sounds/01_cruise_missile.mp3 -o .FFmpeg successfully loaded.analyzing ... 01_cruise_missile.mp3 (1/1): -16.2 LUFS, -6.8 LU (peak: 0.895013: -0.5 dBFS) ALBUM: -16.2 LUFS, -6.8 LU (peak: 0.895013: -0.5 dBFS)writing ... 01_cruise_missile.mp3 (1/1) ... done.
$ ffmpeg -i 01_cruise_missile.mp3FFmpeg version SVN-r26325, Copyright (c) 2000-2011 the FFmpeg developers built on Jan 13 2011 04:17:15 with gcc 4.4.2 configuration: --enable-gpl --enable-version3 --enable-libgsm --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-libvpx --disable-decoder=libvpx --arch=x86 --enable-runtime-cpudetect --enable-libxvid --enable-libx264 --enabl e-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32 --enable-avisynth --enable-w32threads -- cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc' --enable-memalign-hack --enable-shared --disable-static libavutil 50.36. 0 / 50.36. 0 libavcore 0.16. 1 / 0.16. 1 libavcodec 52.108. 0 / 52.108. 0 libavformat 52.92. 0 / 52.92. 0 libavdevice 52. 2. 3 / 52. 2. 3 libavfilter 1.73. 1 / 1.73. 1 libswscale 0.12. 0 / 0.12. 0[mp3 @ 020afe90] max_analyze_duration reached[mp3 @ 020afe90] Estimating duration from bitrate, this may be inaccurateInput #0, mp3, from '01_cruise_missile.mp3': Metadata: title : Cruise Missile artist : Steve Morse Band album : The Introduction TYER : 1984 genre : Dance track : 1 REPLAYGAIN_ALGORITHM: EBU R128 REPLAYGAIN_REFERENCE_LOUDNESS: -23 LUFS REPLAYGAIN_TRACK_GAIN: -6.8 LU REPLAYGAIN_TRACK_PEAK: 0.895013 REPLAYGAIN_ALBUM_GAIN: -6.8 LU REPLAYGAIN_ALBUM_PEAK: 0.895013 encoder : Lavf52.92.0 Duration: 00:05:35.24, start: 0.000000, bitrate: 320 kb/s Stream #0.0: Audio: mp3, 44100 Hz, 2 channels, s16, 320 kb/sAt least one output file must be specified
Quote from: jdoering on 14 January, 2011, 03:02:37 AMThat's completely wrong!It can't be wrong because it's a matter of convention.
What is so special about pink noise? How does pink noise better appromixate the set of all possible audio inputs than a large set of audio inputs?FWIW, analysing my library (a week of FLAC) resulted in a difference of 5.11 dB, similar to the ~5 dB other people got.
Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.
v0.4.6 released[blockquote]http://sourceforge.net/projects/in-ffsox/files/[/blockquote]What's new?Support for mixed ReplayGain and EBU R128 playback added:The configuration allows for defining a relative gain between the two standards, typically about 5 dB. The relative gain can be adjusted according to the user's preferences.It is possible to switch between the normative loudness of both approaches, -23 LUFS and 83 dB, respectively. The respective gains are adapted automatically.If the "Write Comment" is checked RG respective information is written into the File Info's comment fieldDepending on whether the effective gain resulting from RG and pre-amp is an amplification or an attenuation up-sampling is done first or last in the processing chain, respectively, in order to avoid clipping.
It is wrong because it causes existing RG players to malfunction. Exiting players do not know about REPLAYGAIN_ALGORITHM and they assume that existing REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags are in dB units releaive to a -14 dBFS reference. Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.
For a mixed selection of pre-loudness-war material (Kuschelrock Vols. 1 and 2, 4 CDs total), I get an average track-gain difference between the RG and R128 algorithms of exactly 4.6 dB (or LU). Since Raiden got 5.11 dB, I think the 5 dB proposed in Dolby's AES paper are well chosen. Hence, R128gain should write[blockquote]-18 - R128 LUFS loudness[/blockquote]instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.
I agree with Christian, you should write a 'calibrated' gain value, and use dB instead of LUFS. As for calibration, I would think that finding a zero-order adjustment that minimized RMS difference rather than simply the average would be better. I'll test my library as well (huge mix of genres)