/Edit: Ich verwende den Per Track-Modus, ist für mich einfach sinnvoller. Aber die Dateien, die gescannt sind, haben auch einen Album Tag.

Habe heute deine Überarbeitung gelesen, dabei fiel mir auf, das Du noch das falsche "SPL" (Schalldruckpegel) in der Erklärung hattest. Während ich gelesen hatte, hattest Du jedoch "SPL" wieder entfernt.

Zur Verdeutlichung, das es bei der Replay-Gain-Analyse und der Clipping-Prevention sich nicht nur um zwei unabhängige Verstärkerstufen sondern auch um zwei unterschiedliche Messverfahren handelt, wäre es aber von Nutzen wenn Du bei der Replay-Gain-Analyse auf die "RMS"-Analyse (Effektivwert-Analyse) hinweisen würdest.

Gruß TomPro

Wie man sieht, sind unsere eigenen Erklärungsmodelle natürlich auch verbesserungsfähig. Häufig wird immer erst an Fragestellungen wie diesen ersichtlich, an welchen Stellen Verständnisprobleme auftreten, und welche dem Autor vielleicht unmittelbar einsichtigen Erläuterungen genauer ausgeführt werden müssen. Und natürlich erklärt man durch den Zugewinn an Erfahrung heute manche Sachverhalte anders als vor 1-2 Jahren. In diesem Sinne bin ich für jede Anfrage zu den beiden ReplayGain-Artikeln Grundlagen des Konzeptes und Realisierung in foobar2000 dankbar.

Ich merke mir beide mal für eine Überarbeitung vor.

Wer viel misst misst Mist, und so ist das auch in der Audiotechnik. Hier gibt es so viele Bezugsgrößen und Standards, welche aber alle in dB (einer Verhältnis-Einheit) angegeben werden, das man da schon mal was durcheinander bringen kann. Also erläutere ich kurz mein Verständnis von Replay Gain:

Der RMS (auch Effektiv) Level kommt, von allen technischen Pegeln, in seiner Darstellung dem Lautheitseindruck am nächsten, denn hier wird die durchschnittliche Energie gemessen. Der Peak-Level gibt lediglich den technisch höchsten Level wieder, egal ob durch einen Flächensound (viel Energie) oder durch einen Rim-Shot (fast keine Energie). Aus diesem Grunde kommt einem Sprache bei gleichem Peaklevel immer leiser vor als (Pop-)Musik, da ja während der Satz- und Atempausen keine Energie im Signal vorhanden ist, wobei die Musik permanenten Lärm erzeugt (Klassik mal aussen vor).

Also scanne ich jetzt mein Album mit der Vorgabe:
Um wieviel dB müsste ich das Signal anheben oder absenken damit beim Abspielen ein durchschnittlicher Wert von xy dB (RMS) erreicht wird, und zwar sowohl nur der Track alleine (Track-Gain), als auch im Zusammenhang des kompletten Albums (Album-Gain). Da ich bei allen Scanvorgängen, bei jedem Album, den gleichen Referenzwert zugrunde gelegt habe, sollten innerhalb kleiner Toleranzen beim Abspielen die Lieder unterschiedlicher Alben gleichlaut erklingen. Also dem Volkssport des Premastering (Level-Race) genau entgegenwirkend.

Jetzt kann es aber passieren, dass durch die Pegelveränderung beim Abspielen es auf der Peak-Seite, also dem absoluten Pegel, zu einem overflow (einem Wet Höher als 16 Bit => Cliping) kommen kann. Diesem Umstand soll die Clipping-Prevention Rechnung tragen.

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt.

Gruß TomPro

EDIT:
Durch meine langsame Schreibweise kam mir Frank zuvor.

Dieser Zielwert richtet sich also nicht nach deiner Sammlung. Es wird hier kein Mittelwert über alle Alben ermittelt.

Das Verfahren ist bewusst so angelegt, dass die Referenz fest bei 89 dB liegt. Wird vom Scanner eine Lautstärke von 94,3 dB ermittelt, dann wird entsprechend 89 - 94,3 = -5,3 dB im Track- bzw. Album-Feld abgespeichert. Beim Abspielen wird dieser Wert zur Lautstärke hinzuaddiert: 94,3 + (-5,3) = 89 dB; mit dem Resultat, dass der Track oder das gesamte Album mit der Referenzlautstärke abgespielt wird.

Möchte der Benutzer einen anderen Referenzwert verwenden, dann kann dieser beim Abspielen, und es ist für die Flexibilität des Verfahrens wichtig, dass es wirklich erst beim Abspielen und nicht schon beim Scannen geschieht, einen zusätzlichen Lautstärkewert hinzuaddieren, den man mit Preamp bezeichnet.

In foobar2000 kann das beispielsweise so aussehen:

Während sich die in den Tags abgespeicherten Werte immer auf die Referenzlautstärke beziehen, werden beim Abspielen mit diesen Einstellungen nochmal 3 dB auf die resultierende Lautstärke hinzuaddiert, um die Dateien letztendlich mit 92 dB abzuspielen. Natürlich lässt sich auch ein negativer Wert hinzuaddieren um die Ziellautstärke zu senken. Achtung: Beim Erhöhen der Lautstärke kann es zu Clipping kommen.

Würde man den Referenzwert bereits beim Scannen festlegen können, dann wäre zwischen mit unterschiedlichen Referenzwerten analysierten Dateien keine Lautstärkeangleichung mehr möglich, es sei denn man hinterlegt den Referenzwert selbst mit in einem Tag. Tatsächlich ist dies in einer Erweiterung des ReplayGain-Verfahrens vorgesehen, und seit FLAC 1.1.3 ("Support for new REPLAYGAIN_REFERENCE_LOUDNESS tag") möglich und für eine zukünftige MPC-Version geplant. Davon macht aber meines Wissens noch keine Anwendung Gebrauch.

Ich würde den Album ReplayGain bevorzugen. Dieser Gain kann aber meines Erachtens imer nur in Bezug auf die restlichen Alben festgelegt werden, mit dem Ziel, dass alle Alben im Durchschnitt gleich laut klingen. Woher sonst soll der Scanner wissen, auf welchen Pegel er das neu hinzugekommene Album anheben oder absenken sollte? Oder gibt es da einen Referenzpegel, den man dem Scanner vorgibt?

Viele Grüße,
Rudolf

Der Aspekt der Lautstärkeanpassung wird bei der Clippingvermeidung nur dahingehend berücksichtigt, dass der Peak des gesamten Albums berechnet wird, damit sich die Lautstärke aller Tracks gleichmäßig verringert. Zwischen mehreren Alben findet kein Vergleich der Peak-Werte statt. Der Spitzenpegel deiner kompletten Sammlung, also der höchste Wert aus allen Alben (ich vermute, dass du das unter "Referenz-Peak" verstehst), wird vom ReplayGain-Verfahren nicht berücksichtigt. Würde man dies wollen, dann müsste man tatsächlich nach jedem neu hinzugekommenen Album den größten Peak im Archiv heraussuchen und diesen in allen Dateien hinterlegen.

So wie das Verfahren konzipiert ist, scannst du jeweils nur die neu hinzugekommenen Alben.

Alles andere wäre, wie du richtig erkannt hast, nur mit großem Aufwand zu bewerkstelligen und, je länger ich mir das durch den Kopf gehen lasse, wahrscheinlich logistisch garnicht zu realisieren. Man müsste beim Scannen Zugriff auf alle Dateien des Archivs haben, komplette Backups müssten ebenfalls aktualisiert werden und so weiter. Dies würde wahrscheinlich in keinem gesunden Verhältnis zum eigentlichen Nutzen stehen. Das Verfahren hat hier sozusagen eine bewusst in Kauf genommene, aber letztendlich nur vernünftige Schwachstelle.

Viele Grüße,
Rudolf

ich habe jetzt mehr oder weniger den Großteil meiner Sammlung angepasst. Lustigerweise gab es ein Problemmit der Albenerkennung so dass nun ca. 4000 Lieder als ein Album aufgefast wurden  :rolleyes: . Da ich aber gemerkt habe, dass ich eh fast nur Track-Gain verwende, ist das erstmal nicht weiter schlimm. Selbst bei Klassik-Alben benutze ich das Album-Gain eher nicht, weil ich normalerweise wegen dem hohen Dynamikumfang bei leisen Stellen lauter und bei lauten leiser stelle. Mein kleines Studentenzimmer ist leider nicht der allerbeste Hörraum :( Und wenn ich mich doch vollends auf ein Album und seine Dynamik konzentrieren möchte, kann ich auch noch gerade den Regler manuell einstellen.

Ansonten finde ich Track-Gain doch sehr gut, besonders wenn man sich mit diversen "intelligenten" Abspielfunktionen die zB von Amarok bereitgestellt werden, quer durch die Musiksammlung hangelt. Trotzdem höre ich je nach Musikrichtung und auch Tageszeit mal leiser und lauter, das kann mir (bisher) noch kein Verfahren abnehmen.

Kann man nun mit berechneten Album-Gain quasi "on the fly" Track-Gain verwemden, oder wie muss man sich das vorstellen.

Wenn man eine Auswahl von Titeln als Album analysiert, dann berechnet der ReplayGain-Scanner gleichzeitig die Werte für die trackbasierte und die albumbasierte Anpassung und legt sie in den Tags der Datei ab. So ist es jedenfalls in foobar2000 und jüngst auch Winamp. Bei amaroK weiß ich es nicht, würde mich aber wundern wenn man dort nur die Albumwerte berechnen würde.

Welche Werte verwendet werden, bestimmt die Einstellung im Player.

Genau, auch das hast du richtig verstanden. Lässt man die Dateien nur trackbasiert analysieren, dann kann beim Abspielen anhand dieser Werte keine albumbasierte Lautstärkeanpassung erfolgen.

ich habe vor kurzem meine komplettes "Musikabspiel"-System neu aufgesetzt und möchte von nun an auch ReplayGain benutzen. Hierbei verwende ich bei normalen Alben (1 Artist/Album) Album-Gain, beim Rest will ich eigentlich Track-Gain verwenden (was das Berechnen angeht).

Nun kann man aber scheinbar auch während der Wiedergabe bei vielen Playern zwischen Album und Track auswählen, nur was heißt das denn konkret? Kann man nun mit berechneten Album-Gain quasi "on the fly" Track-Gain verwemden, oder wie muss man sich das vorstellen. Anders rum kann ich mir dasauf jeden Fall nicht vorstellen.
Weil wenn man sich das ja direkt bei der Wiedergabe aussuchen muss, fällt die Entscheidung beim Berechnen ja viel leichter.

PS: Also ich persönlich benutze Amarok mit dem ReplayGain-Script.

Titel scannen:   

Einstellungen für das Replaygain vornehmen:

Wie mache Ich Winamp (mit in_mpg123 Plugin) denn jetzt klar, daß er die FLAC Alben auch auf ~92db abspielen soll, oder geht das nur mit foobar?

Hast du dich hier verschrieben, oder geht es dir tatsächlich um FLAC-Dateien?

In diesem Fall ist das Input-Plugin für FLAC für die Auswertung der ReplayGain-Tags zuständig, nicht das MP3-Plugin. Bei Winamp werden diese Werte gegenüber foobar2000 nicht zentral gesammelt und ausgewertet, es gibt auch keine einheitliche Konfigurationsseite für alle Formate, sondern jeder Decoder ist für die Implementierung von ReplayGain selbst verantwortlich, womit sich auch die Anpassungsmöglichkeiten von Codec zu Codec unterscheiden.

Stell den Preamp-Wert im FLAC-Plugin auf +3 dB, dann hast du 92 dB.

PS: Wir beantworten für gewöhnlich keine Fragen, die sich auf eine konkrete Software beziehen.

Ich lasse mich aber gern berichtigen, falls es evtl. mit dem MAD-Plugin oder einer anderen Alternative funktioniert.