Talk:ReplayGain

This is the talk page for discussing improvements to the ReplayGain article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.

Professional sound production Mid‑importance

	This article is within the scope of WikiProject Professional sound production, a collaborative effort to improve the coverage of sound recording and reproduction on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Professional sound productionWikipedia:WikiProject Professional sound productionTemplate:WikiProject Professional sound productionProfessional sound production
Mid	This article has been rated as Mid-importance on the project's importance scale.

normalize

Hi, please don't add normalize to the article. It's an RMS-normalizer, not an RG-scanner. --Kjoonlee 03:01, 24 August 2006 (UTC)[reply]

Maybe a link from the "Alternatives" section could work, but please don't list it as an RG-scanner. :) --Kjoonlee 06:31, 24 August 2006 (UTC)[reply]

WinAmp has native RG support in 5.25

From version history of Winamp 5.25 beta build 868

New: Replaygain support for MP3, AAC, Vorbis and M4A
New: [ml_rg] replaygain scanner (access via Send To menu)
Improved: [in_mp3] replaygain support for MP3 playback

Noccy80 10:38, 23 September 2006 (UTC)[reply]

Hardware support

I know that there is at least one hardware DAP, probably several, that support ReplayGain-tagged data. Notably the Rio_Karma. Mojo Tooth 23:52, 11 May 2007 (UTC)[reply]

Logitech Squeezebox[1] series of hardware players support RG. Navporky (talk) 07:05, 23 June 2009 (UTC)[reply]

The Sansa Clip/Clip+ flash DAP now both support ReplayGain with the newest firmware. Clip+ review:[2] also mentions that the Clip has upgraded its firmware to support Replay Gain. —Preceding unsigned comment added by 12.53.118.3 (talk) 00:24, 1 September 2009 (UTC)[reply]

contradiction

"Another benefit of Replay Gain scanning is that the peak information can also be used to prevent loud songs from clipping." (http://en.wiki.x.io/wiki/Replay_Gain) contradicts "Audio volume leveling, prominently Replay Gain, is perhaps the most widely used solution. It should be noted, however, that this can only reduce the volume of loud music so that it is not proportionately louder than the listener's other music. It cannot restore dynamics or undo clipping." (http://en.wiki.x.io/wiki/Loudness_War) --boarder's paradise (talk) 08:44, 8 August 2008 (UTC)[reply]

Wrong. Replay Gain can increase volume. It cannot undo clipping, but it can prevent new clipping. --Kjoonlee 09:57, 8 August 2008 (UTC)[reply]

That contradiction is due to the common (but incorrect, IMO) practice of applying a post-gain after replaygain to try and make everything loud again. (This is where the "prevent-clipping" options on many players come in. They're detecting whether the post gain is greater than the RG attenuation by sufficient margin to put the peak at above full scale, and must either do something lossy to avoid clipping, or further attenuate the track, defeating the whole purpose of replaygain. A better way to accomplish the same goal of matching RG tagged and untagged tracks in level is to have a configurable fixed attenuation applied to all non-RG tagged tracks and then turn up the volume knob. Foobar2000 does have this option, but it's quite rare otherwise.Nwimpney (talk) 21:46, 7 September 2015 (UTC)[reply]

I have edited this section to clarify and hopefully avoid apparent contradiction. ~Kvng (talk) 23:15, 10 September 2015 (UTC)[reply]

What was the point of this revert?

(B R D) What was the point of this revert? --Damian Yerrick (talk | stalk) 16:07, 8 August 2008 (UTC)[reply]

Well, assuming you have headroom, it's always possible to increase the amplitude by 2, and get away with it. Also, MP3 files have a scalefactor for each frame, which lets you change the volume of the file. If you change the scalefactor, then the frame will be scaled using a different factor (the new scalefactor) which allows you to modify the volume of existing MP3 files. --Kjoonlee 12:14, 10 August 2008 (UTC)[reply]

"Directly modifying" is meant to mean changing the scale factor or something similar, and saving under an existing name.
"Creating a new copy" is meant to mean amplifying the samples by an arbitrary amount, and saving under a new name.

Could this be improved? --Kjoonlee 12:18, 10 August 2008 (UTC)[reply]

So we have discovered three issues with this wording that need improvement. I'll add section breaks below. --Damian Yerrick (talk | stalk) 01:05, 11 August 2008 (UTC)[reply]

Wave times two

Sure, one can multiply all samples by 2 or any other integer as long as they don't exceed the rails. But can one multiply all samples by 7/5 without introducing noise? --Damian Yerrick (talk | stalk) 01:05, 11 August 2008 (UTC)[reply]

You can multiply all samples by 2 or 4 or any other power of 2 as long as it doesn't clip. Consider amplifying a 16 bit file 256 times to get a 24 bit file. --Kjoonlee 04:00, 11 August 2008 (UTC)[reply]

I'm aware of that. And I can multiply all samples by 3 to get a 9.54 dB boost (20 log₁₀ 3) as long as all samples are within ±0.33. But if I multiply by something other than an integer, is it reversible? Specifically, if I reduce the volume of a pop song ripped from an overcompressed CD to a 16-bit PCM file, is it reversible? --Damian Yerrick (talk | stalk) 15:27, 11 August 2008 (UTC)[reply]

Headroom can arbitrarily be added at any point by adding bits to the top of your samples. Where the inevitable problems occur is at the final playback stage, where everything is right against 0dBFS. Even if you have calculated a perfect scaled output, you can't play it back without clipping at levels where the peaks will clip. If you're playing it back at quieter levels, it makes more sense to always attenuate, and add your extra bits at the bottom instead.Nwimpney (talk) 21:53, 7 September 2015 (UTC)[reply]

Directly modifying

I thought "directly modifying" meant changing the samples, which as far as I know adds noise, and saving under the same name. This is the "destructive" approach. --Damian Yerrick (talk | stalk) 01:05, 11 August 2008 (UTC)[reply]

I know of no utility that actually work that way. You could do it in any audio editor, but it would still be "saving a new copy with the volume modified." --Kjoonlee 04:02, 11 August 2008 (UTC)[reply]

MP3 scalefactors

To what precision does MP3 store its scalefactors? Can I scale all the scalefactors in an MP3 stream by 7/5 and then by 5/7 without introducing noise? And what other popular lossy codecs have values analogous to scalefactors? I'm guessing Vorbis "floor" curves are something like them. --Damian Yerrick (talk | stalk) 01:05, 11 August 2008 (UTC)[reply]

Assuming you don't get wrap-around errors, normal changes to the scalefactor will be reversible. If you increase the scalefactor 1 unit, then volume will be increased by 1.5 dB. If you decrease the scalefactor 1 unit, then volume will be decreased by 1.5 dB. --Kjoonlee 03:54, 11 August 2008 (UTC)[reply]

AAC has something similar as well. With Vorbis, it gets complicated.[3] --Kjoonlee 03:56, 11 August 2008 (UTC)[reply]

Who created this proposed standard?

Who created this proposed standard? 86.174.124.149 (talk) 14:18, 1 August 2009 (UTC)[reply]

David Robinson. Binksternet (talk) 14:49, 1 August 2009 (UTC)[reply]

Windows Mobile or Google OS support

Since the article discusses PMPs/MP3 players, it would be nice to know about any players with ReplayGain that work on mobile devices. A.k.a. (talk) 18:08, 15 January 2010 (UTC)[reply]

89 db?

From the article: “the target loudness of most Replay Gain utilities is 89 dB”. When we’re dealing with actual sounds, 89 dB is an objective measure. But Replay Gain utilities deal with digital recordings. The same digital recording will be played back at different dB levels on different hardware (sometimes drastically different—think movie theater vs. headphones). So, what does this “89 dB” actually mean for digital recordings? To put it simply, in a PCM range of 0.0 (silence) to 1.0 (full volume), where does this “89 dB” fall? John lindgren (talk) 03:01, 25 August 2010 (UTC)[reply]

:What I've gathered is that ReplayGain assumes 16-bit CD audio and references 0 dB to the noise floor and that makes 96 dB is full scale. 89 dB is 7 dB below full scale. A bit wacky. It is more common to use 0 dB as your full-scale reference (and -96 dB would be your noise floor for 16 bit audio) --Kvng (talk) 04:16, 25 August 2010 (UTC)[reply]

ReplayGain is not referenced to 16-bit audio at all. The calibration is explained here... http://replaygain.hydrogenaudio.org/calibration.html ...all current implementations add 6 to the value before storing it, hence the reference is now 83+6=89dB. 85.158.45.57 (talk) 13:38, 8 September 2010 (UTC)[reply]

Disregard my previous comment. Here's an up-to-date explanation of the reference level. --Kvng (talk) 22:39, 18 January 2011 (UTC)[reply]

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. Vegaswikian (talk) 19:33, 19 July 2011 (UTC) Page moved. After additional input on my talk page, it is clear that there was support. So I have reversed my initial close and moved the page based on the discussion. Vegaswikian (talk) 23:04, 26 July 2011 (UTC)[reply]

Replay Gain → ReplayGain – David Robinson, the original publisher of the proposal, has declared preference for the single-word name ReplayGain. See discussion at HydrogenAudio for verification. Kvng (talk) 17:09, 12 July 2011 (UTC)[reply]

But has common usage followed suit? I don't think so. Binksternet (talk) 18:02, 12 July 2011 (UTC)[reply]

One of the stated reasons for the change was to follow common usage. What leads you to beleive that ReplayGain is not in common use? --Kvng (talk) 19:46, 12 July 2011 (UTC)[reply]

No move. Rather than looking at the hydrogenaudio forum discussion, which I expect supports the position that the CamelCase one-word version is now commonly used, I looked for reliable sources. I found this book from 2006, this one from 2007 and this one from 2009; all using two words Replay Gain. However, when I searched Google Books for the CamelCase version, I got zilch. That's why I think the move is not yet justified. Binksternet (talk) 21:09, 12 July 2011 (UTC)[reply]

The decision to change to ReplayGain was based on it having significantly more hits in a standard web search. Not a lot of research or discussion went into it. Someone suggested the change then David Robinson said he preferred to change it and thus it was so.
I believe it is clear that both Replay Gain and ReplayGain are in common use. I don't think it is useful to argue about which is more common - a case can be made for either.
What else is there to go on? Should not the wishes of the developer and title of the current official specification factor in to this? --Kvng (talk) 22:34, 12 July 2011 (UTC)[reply]

I'm not going to lose any sleep either way—the naming issue is not crucial to me. Let's see what others think! Binksternet (talk) 22:45, 12 July 2011 (UTC)[reply]

Support move - If both versions of the name are roughly equally common, then going with the official name is probably the way to go. I get twice as many google hits for "replaygain" as I do for "replay gain". —SW— ^chatter 16:38, 14 July 2011 (UTC)[reply]

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on ReplayGain. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive http://web.archive.org/web/20090129163032/http://www.gasteropod.net:80/ to http://www.gasteropod.net/
Added archive http://web.archive.org/web/20040202010803/http://www.musicex.com:80/mediacenter/ to http://www.musicex.com/mediacenter/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 00:54, 21 March 2016 (UTC)[reply]

Fixed www.musicex.com link Robert.Harker (talk) 03:26, 21 March 2016 (UTC)[reply]

‘Target loudness’ section confusing volume (unweighted, measured in dBFS) and loudness (perceptually weighted, measured in LUFS)

The section claims that ReplayGain’s target volume is 89 dB SPL, or −14 dBFS. This is not, and has never been, true.

The original ReplayGain specification defines the target as the loudness of a stereo pink noise signal played at −14 dBFS, or 89 dB SPL. ReplayGain 2.0 changes the loudness measurement algorithm to ITU BS.1770-3 and targets −18 LUFS, which is a value chosen to match the prior ‘pink noise at −14 dB’ target closely and keep compatibility (source). Most ReplayGain scanners use ReplayGain 2.0.

The section also claims that EBU R128 recommends 23 dB of headroom, i.e. a normalisation to −23 dBFS. This is likewise untrue; the recommendation is −23 LUFS. 2003:F3:4F23:F100:B317:D894:5714:2BB (talk) 16:42, 19 July 2023 (UTC)[reply]

For the most part, the article covers the original specification and I don't see where it gets that wrong. Glad to hear that 2.0 has received attention but I'd like to see a source that backs up the claim that Most ReplayGain scanners use ReplayGain 2.0.. Normalisation to −23 dBFS is 23 dB of headroom, by definition really. ~Kvng (talk) 14:40, 23 July 2023 (UTC)[reply]