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 articles
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 articles
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
Latest comment: 8 years ago4 comments4 people in discussion
"Another benefit of Replay Gain scanning is that the peak information can also be used to prevent loud songs from clipping." (http://en.wikipedia.org/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.wikipedia.org/wiki/Loudness_War) --boarder's paradise (talk) 08:44, 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
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. --Kjoonlee12: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.
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. --Kjoonlee04: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 log103) 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
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." --Kjoonlee04:02, 11 August 2008 (UTC)Reply
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. --Kjoonlee03:54, 11 August 2008 (UTC)Reply
Latest comment: 14 years ago1 comment1 person in discussion
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
Latest comment: 13 years ago4 comments3 people in discussion
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
Latest comment: 13 years ago8 comments4 people in discussion
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
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
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—chatter16: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.
Latest comment: 8 years ago2 comments2 people in discussion
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:
When you have finished reviewing my changes, please set the checked parameter below to trueorfailed to let others know (documentation at {{Sourcecheck}}).
YAn 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.
Latest comment: 11 months ago2 comments2 people in discussion
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.
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