Bug 4786 - Automatic Replay Gain
: Automatic Replay Gain
Status: RESOLVED DUPLICATE of bug 3152
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: unspecified
: All All
: -- enhancement with 1 vote (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-25 04:21 UTC by Nicola Fankhauser
Modified: 2013-06-07 15:42 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicola Fankhauser 2007-02-25 04:21:27 UTC
Automatic Replay Gain as a feature would be nice to have. This would especially be interesting for frequently changing material coming from various sources.

Implementation could be done in the scanner (offline) or asynchronously in the background before playing a certain track (look-ahead in the playlist), or simply after having played the track.
Comment 1 KDF 2007-02-25 09:57:57 UTC
could tie in a bit with bug 3152
Comment 2 Chris Owens 2007-02-27 09:09:01 UTC
Nicola, how are you thinking this should work?  Are you advocating that Slimserver actually scan the music data and set replaygain tags at scan-time?

Comment 3 Nicola Fankhauser 2007-02-27 09:44:39 UTC
Chris, I think it could be done without much overhead while playing. Given what is proposed in #3152 (gain preset) it would play music that has no replay gain tags and re-adjust the gain continously (downwards only) to match a given maximum loudness preset. after having played the track, it would write the tags accordingly back to the music file.

If you need more explanation of my idea, just ask.
Comment 4 Chris Owens 2007-02-27 15:41:50 UTC
I'm going to flag this so we can consider it at a future engineering meeting.  It'll remain open so you can add more info if you want, or encourage people on the forums to add their ideas as well.
Comment 5 Mike Walsh 2007-05-17 08:43:53 UTC
just as an aside...

i haven't figured out how to set RG tags in my mp3s yet.  i know i need to run a 3rd party pgm to do so, and get track/album RG amounts set in the tags.  its confusing and scary, i don't want to make a mistake, i have enough tag issues.  and i certainly don't want to alter the encoded music itself, i just want to set a tag value.

for people like me, if SS could simply handle it without me getting a phd in RG and tags, that would be great.

SO...

when u rip with newer LAME binaries and EAC, (and other pgms too probably) LAME itself will calculate a RG value as it encodes, and stick it in the LAME header, (separate from id3 type tags).

a lot of my mp3s then already have a value calculated for tracks anyway, right in the lame header.  it would be nice if u could configure SS to simply take advantage of this info reading it on the fly, OR

have the scanner simply read it and store it in the DB for use.

the pgm that can read this info is at:

http://thelion.fm/mp3tools/LameTag/

the orig website i got it from is very hard to reach.  so i posted it there.

personally, i'd want one set reference point of loudness, and have it go up or down to meet that point.
Comment 6 Mike Walsh 2007-10-31 12:53:08 UTC
the new winamp will do RG tags for album and track, and do it easily.  so i now know how to get them into my tags.

given that, i think it might be a bad idea to have SS write to tags, even if it were configurable, since SS has always seemed to have a "no writing policy."

i do still think it would be a good idea for SS to be able to use the mp3 LAME header value.

it would also be nice if SS were smart enough to know when to use track gain, and when to use album gain, which should be based on upcoming playlist.
Comment 7 Mike Walsh 2011-03-13 14:52:45 UTC
bug 2431
Comment 8 Alan Young 2011-11-06 23:23:17 UTC
Unassigned bugs cannot have a priority.
Comment 9 Michael Herger 2013-06-07 15:42:46 UTC

*** This bug has been marked as a duplicate of bug 3152 ***