Es ist schon ok, dass die Verstärkung nicht über 1 (0dB) geht.
In foobar2000 hat man in den Preferences die Option bei der Wiedergabe “apply gain and prevent clipping according to peak”,
d.h. die Verstärkung wird soweit zurückgedreht, dass die Peaks auf maximal 0dBFS reichen.
Ich sehe es eher so, dass die Anpassung der physiologisch gleichlaut empfundenen Lautstärke auf eine Dämpfung (negative Verstärkung) hinausläuft.
Im Endeffekt sind dann aber die Träcks ähnlich in der empfundenen Lautstärke (darin liegt ja die Arbeit des ReplayGain Algorithmus).
Die verlorene Lautstärke wird dann einheitlich z.B. im Mischpult wieder aufgeholt.
Eine ähnliche Diskussion hatte ich hier schon mal angestossen: http://forum.mairlist.com/index.php/topic,4359.0.html
Wobei wir mittlerweile alle mp3s auf -89dBSPL gesetzt haben und den Pegel am Mischpult auf +3dBu gesetzt haben.
Zur “Kalibration” des Playout-PC zum Mischpult hin habe ich die Rosa-Rauschen-Datei von Replay-Gain benutzt welche auf 89dB Pegel gesetzt wurde und preset wird dann beim Abspielen der selben auf +3dBu gesetzt. http://replaygain.hydrogenaudio.org/ref_pink.wav
Der Rest macht ein äussert weicher Kompressor mit “interactive Knee” Funktion dem ein Limiter nachgeschaltet ist.
Deshalb ist unser Preset vom “mAirList” Fader auch blockiert und nicht für den Moderator veränderbar.
Das Problem ist hier immer wieder “Schulung der Moderatoren” daran scheitert es immer wieder. Und wo man nix drehen und verstellen kann, da geht auch nix schief. (K.I.S.S. halt)
Jean, bei deinem letzten Besuch hatte ich das Thema Pegel mal kurz angesprochen.
Ich denke dein Problem liegt darin dass eure Tracks alle in FLAC sind, oder? Es gibt wahrscheinlich kein Programm à la mp3gain was die Datei entsprechend absenken kann, oder?
Torben, wir benutzen ja nicht die Datenbank; ein “Player embedded Replay Gain”, wie würde sich das auf Ladezeiten auswirken wenn keine Absenkwerte in der Datenbank gespeichert sind. Der Track müsste zunächst ja zunächst mal analysiert werden bevor er in der Playlist landet.
So eine Funktion wäre schon nicht schlecht weil einige (unbelehrbare) Moderatoren immer irgendwelche Tracks auf USB Stick mitschleppen welche nicht auf 89 dBSPL geleveled sind (muss ja schön laut sein im mp3-Player…)
So eine Funktion würde das schon mal lösen.
Oder liege ich falsch in meinen Annahmen betreffend dieses Thema?
egal ob FLAC, oder mp3, beide Formate können die Informationen von ReplayGain abspeichern.
Es geht mir in erster Linie darum, dass zwischen den einzelnen Tracks kein zu grosser Unterschied im Lautheitsempfinden entsteht,
das bedeutet, dass die heute produzierten Briketts runtergeregelt werden müssen, während Tracks mit einer Dynamik wie sie in den 70er Jahren noch üblich war, eventuell unangetastet bleiben. Das erleichtert den Moderatoren die Aussteuerungsarbeit.
mAirList soll die Dateien nicht selbst analysieren, sondern nur den vom CD-Ripper etc. in die Tags geschriebenen ReplayGain-Wert auslesen und beim Abspielen entsprechend berücksichtigen.
mAirList soll die Dateien nicht selbst analysieren, sondern nur den vom CD-Ripper etc. in die Tags geschriebenen ReplayGain-Wert auslesen und beim Abspielen entsprechend berücksichtigen
bei der Analyse einer Audiodatei werden vier ReplayGain Daten errechnet und anschliessend in den Metatags abgelegt.
Es sind dies:
replaygain_album_gain (in dB)
replaygain_album_peak (als Zahl)
replaygain_track_gain (in dB)
replaygain_track_peak (als Zahl)
Da ich meine Audiofiles (FLAC) immer auf -1 dBFS normalisiere, finde ich in den beiden Feldern replaygain_track_peak und replaygain_album_peak dann auch konsequent den Wert 0.891266 = -1dBFS.
Bei der Wiedergabe mit ReplayGain müssen (laut foobar2000) nun folgende Optionen möglich sein:
Auswahl, welcherReplayGain-Wert ausgelesen wird
Source mode:
none (ReplayGain-Daten werden nicht berücksichtigt)
track (der Gain-Wert replaygain_track_gain wird berücksichtigt)
album (der Gain-Wert replaygain_album_gain wird berücksichtigt)
Processing, welchem die Datei dann unterzogen wird
none
apply gain
apply gain and prevent clipping according to peak
prevent clipping according to peak (???)
Die Option “apply gain and prevent clipping according to peak” verhindert es, dass ein Gain benutzt würde, welcher Peaks über 0dBFS anheben würde.
In meinem Fall von auf -1dBFS normalisierten Audio-Files ist dann ein ReplayGain-Wert für Verstärkung von maximal +1dB möglich.
In der Regel werden zur Lautstärkeanpassung aber eher negative Verstärkungswerte errechnet, was also auf eine Dämpfung hinausläuft.
Es geht ja letztendlich um eine Anpassung der Lautstärke zwischen Files.
Werden bei eingestelltem Album-Modus keine albumbasierten Werte in den Dateien gefunden, weil diese ursprünglich nur als Einzeltracks analysiert wurden, dann werden die trackbasierten Werte verwendet. Der umgekehrte Fall kann nicht eintreten, da bei der albumbasierten Analyse immer auch Track Gain und Track Peak ermittelt werden. Befinden sich in einer Datei keine ReplayGain-Informationen, dann bleibt ihre Lautstärke unangetastet.
Ja, genauso habe ich mir das gedacht. Vermutlich werde ich es aber als drei Ankreuzboxen realisieren, viel weniger Arbeit für mich:
ReplayGain auslesen
Album-Wert verwenden falls verfügbar
Clipping
Das wären dann drei weitere Optionen unter “Datei-Import”.
Noch zu den MP3-Dateien: Die Werte können ja wahlweise im ID3v2-Tag oder im APE-Tag stehen. mAirList unterstützt im Moment aber nur ID3-Tags. Darf ich davon ausgehen, dass jede Software, die den ReplayGain-Wert ermittelt, den auch im ID3v2-Tag unterbringen kann?
Übrigens, kann mir mal jemand eine Software nennen, die vorhandene Dateien analysiert und den ReplayGain-Wert in die Tags schreibt? Ich brauche was zum Testen…
Wobei ich nur noch kurz zum Überdenken anstossen will.
Mp3Gain verändert ja das “global gain” Feld von jedem Frame um die Lautstärke anzupassen.
Zusätzlich wird das Ganze nochmal im APE Tag abgelegt.
Was ist denn nun wenn mAirList jetzt noch zusätzlich diesen Wert aus dem APE-Tag mitberücksichtigt?
Nicht dass man dann noch mal den bereits über das “global gain” abgesengten Track zusätzlich absenkt.
Oder wie wird das konkret unterschieden? Dass das “glabal gain” Feld bereits verändert wurde weiss mAirList ja nicht…
So, dann testet doch bitte mal Build 803, der nun bereitliegt.
Es gibt nun wie angekündigt die drei neuen Datei-Import-Optionen. Zur Zeit wird der ReplayGain in MP3-, OggVorbis- und FLAC-Dateien erkannt. Ein paar Anmerkungen:
Was MP3 betrifft, gibt es zwar einen Standard (RGAD-Frame im ID3v2.3.0-Tag), den aber niemand nutzt. Stattdessen bringen die getesteten Programme (foobar2000, MediaMonkey) die Wert in TXXX-Frames unter. Diese Variante habe ich nun erstmal implementiert. Angeblich gibt es auch noch eine weitere Möglichkeit (LAME-Header), das habe ich mir aber noch nicht angesehen.
Es gab in dem Zusammenhang einen Bug in der von mir verwendeten ID3-Library (JVCL) - die von foobar2000 geschriebenen ID3v2.4.0-Tags konnten nicht korrekt ausgelesen werden. Ich habe einen Workaround eingebaut, so dass die Tags nun (in den meisten Fällen) ordentlich verarbeitet werden dürften.
Grundsätzlich gilt: mAirList liest den ReplayGain-Wert nur einmal im Rahmen des Datei-Imports aus (in die Datenbank, bzw. beim Reinziehen in die Playlist). Der Wert wird dann als Verstärkung (Amplification) im Playlist-Element gespeichert (kann im PFL-Dialog kontrolliert werden). Wenn der ReplayGain-Wert im Tag nachträglich geändert wird, erkennt mAirList das nicht. Das ist dasselbe Prinzip wie beim Auslesen der herkömmlichen Tags - auch die schaut mAirList nie wieder an, wenn es “bessere” Informationen in der Datenbank, in MMD-Dateien oder wo auch immer gibt.
Viel Spaß beim Ausprobieren. Ich freue mich über Rückmeldungen.
Ich wollte nur darauf hinweisen, dass falls man die Datenbank nutzt, evtl. veränderte Tags (und dazu zählt auch der ReplayGain-Wert) nachträglich nicht mehr erkannt werden. Eben weil der ReplayGain aus dem Tag als “Amplification” in der mAirListDB weiterlebt.
Dasselbe gilt, wenn du eine Playlist in einem der mAirList-XML-Formate (.mlp, .mld, .mlt) speicherst, oder wenn du einen mAirList-Datei-Tag oder eine MMD-Datei erzeugst. Auch dann verwendet mAirList nur noch seine eigenen Metadaten und schaut sich evtl. veränderte Tags nicht mehr an.
Ich hätte da ja noch ein ganz andere blöde Idee: Wie wäre es denn, wenn mAirList den ReplayGain-Wert ggf. selbst ermitteln kann?
Ich stelle es mir so vor: Wenn ich eine Datei in die Playlist ziehe (oder woher auch immer) und dann die Eigenschaften oder den PFL-Dialog öffne, habe ich dort die Möglichkeit, die Datei zu scannen und dann entsprechend in der DB, im Tag oder mmd abzuspeichern. Ungefähr verstanden?
Allerdings taucht hier u.U. wieder das Lizenzierungs-Problem auf, würde ich mal vermuten…
Viel Spaß beim Ausprobieren. Ich freue mich über Rückmeldungen.
Hallo Torben,
ich habe jetzt mal einige Versuche unternommen:
Ausgangspunkt, FLAC Dateien:
1.1 Sine 1kHz 10sec 0dBFS ohne ReplayGain
1.2 Sine 1kHz 10sec -10dBFS ohne ReplayGain
2.1 Sine 1kHz 10sec 0dBFS mit ReplayGain
2.2 Sine 1kHz 10sec -10dBFS mit ReplayGain
ReplayGain für Track wurde mit foobar2000 errechnet und in die Metadaten für die Files mit ReplayGain geschrieben:
für 2.1: Track Gain = -14.18dB
für 2.2: Track Gain = -4.18 dB
Dann habe ich die Files in mAirList abgespielt (jeweils im Automatikmodus zuerst die 0dBFS und dann die -10dBFS).
Ich habe die Files sowohl über die Datenbank als auch aus dem Explorer in den Player reingeholt.
Beim Abspielen habe ich dann den Pegel auf dem RTW geprüft (Ausgang ist so kalibriert, dass 0dBFS 0dB=+6dBu am RTW entsprechen).
Die Files ohne ReplayGain ergaben 0dB/-10dB Anzeigen.
Die Files mit ReplayGain führten zum gleichen Resultat. In den Attributen ist allerdings der ReplayGain-Wert zu finden.
