Moin Moin zusammen,
ich glaube ich sehe den Wald mal wieder nicht, vor lauter Bäumen.
Unser Normalisierungsprozess soll umgestellt werden. Weil das im laufenden Programm passieren muss, möchte ich die Playliste nach den aktuellen Voreinstellungen normalisieren lassen, nachdem sie für die Stunde geladen wurde.
Einen Befehl gibt es dafür nicht, ich vermute es braucht ein simples Script?
Greetz
Malte
Das hat nichts mit dem Wald zu tun. 
Die Aufgabe lautet:
Problem dabei: Wir müssen den aktuell spielenden Titel davon ausnehmen. Den kannst du während des Ausspielprozesses nicht einfach so normalisieren (glaube ich zumindest).
So was ähnliches kam (intern) schon mal bei extern zugespielten Nachrichten auf, ob man die nicht regelmäßig (nach der Aktualisierung) normalisieren könne.*
Nein, derzeit nicht; zumindest nicht nach dem aktuellen Procedere.
Möglicher Ansatz, vielleicht was für die Script-Schreiber:
So, wie mAirList immer die nächsten [n] Titel vorpuffert, könnte man im Rahmen eines rolling forward die NEXT plus [n] Titel normalisieren lassen.
Ob und, falls ja, wie schnell und einfach sich so ein Befehl realisieren ließe? Interessante Idee.
Vielleicht sogar vor der v7? 
* Nachrichten: Man sollte davon ausgehen, dass extern zugelieferte Nachrichten immer in der gleichen Qualität und Lautheit zugespielt werden, auch von professionellen Anbietern. Eigentlich eine Selbstverständlichkeit.
Dem ist leider nicht so, wie einige Kunden von uns leidvoll erfahren mussten. Daher schon mal die Frage, ob die Nachrichten als festes Datenbank-Element nicht regelmäßig neu normalisierungsfähig wären. Problem: Woher weiß mAirList, dass sich der Inhalt des Audio-Elements geändert hat?
Und wie lautet das Zauberwort für „normalisiere“ in mAirList Script?
Die Normalisierung kann da stumpf drüber laufen. Geht zumindest bei der manuellen Variante. Gibt ggf. Einen kleinen Pegelsprung, des laufenden Titels, damit kann ich in diesem Fall leben.
Das Thema externer Content kam auch gerade auf. Das sind 1 bis 2h Elemente, da müsste ich vorher über die Datenbank die Normalisierung triggers aber wie mache ich das, da müsste ich ja bestimmte Elemente zu einer bestimmten Zeit lesen lassen.
Das gleiche Problem habe ich in dem Fall mit dem Cue-Sheet.
Ich fürchte, da werde ich Torben am Montag mit nerven müssen, wenn er für so was gerade auf Empfang ist.
Wahrscheinlich wird er etwas zaubern müssen, vermute ich mal so frei raus.
Dass ich aber auch immer so merkwürdige Ideen habe… 
Trotzdem, danke für den Hilfeverauch am Sonntag.
Bleibt wahrscheinlich das automatische anwenden von massenbearbeitung auf generierte Playlisten. Das ad-hoc normalisieren, wird sich heute hoffentlich erledigen.
Genau da pfeffert der Hase: Das oder die Elemente stehen in der Datenbank mit einem festen Verstärkungswert und einer einmalig errechneten Lautheit (siehe Element-Eigenschaften). Und wir haben noch keinen klaren Automatismus dafür ausgewürfelt, wie man das quasi laufend überprüft und ggf. anpasst.
Zumindest nicht so leicht auf das aktuelle Datenmodell anpassbar, um mal ein wenig zu spoilern. Aus dem Testlabor höre ich nämlich mitunter leise Flüche, dass bestimmte Anforderungen und interessante Erweiterungen derzeit nicht realisierbar sind; wir stoßen an Grenzen.
Ich weiß zwar selber noch nichts genaues, aber wir bewegen uns für neue Versionen scheinbar irgendwo zwischen einer Rad-Neuerfindung und einem “sorry, geht nicht anders”.
Ich bin selber gespannt wie ein Flitzebogen.
Was genau ist da das Problem?
Meine persönliche Vermutung ist ja, dass das mit dem Verstärkungswert zur Realisierung einer gleichbleibenden Lautheit nach EBU R 128 (seit v6.2) auch nur ein Zwischenspiel ist.
Torben hatte sich zu seinen langfristigen Plänen diesbezüglich mal am Rande einer Diskussion geäußert. Irgendwann finde ich auch die Textstelle, daher nur grob aus dem Hinterkopf:
mAirList soll zukünftig beim Laden in den Player (!) berechnen, wie groß die Differenz zwischen Ist (errechnete Lautheit) und Soll (Vorgabe der Lautheit in der Konfiguration) ist und das dann selbständig entsprechend ausspielen. Der Player an sich braucht dann nur noch den Lautheitswert und den gewünschten Zielwert.
Damit wäre die Sache mit dem Verstärkungswert vom Tisch.
Blöderweise löst das nicht das Nachrichtenproblem mit den wechselnden Inhalten. Denn die diesem Element mitgegebene, errechnte Lautheit ändert sich ja nicht automatisch mit… 
Ich würde mir da ggf. mit einem Event behelfen. Um xx:45 wende Script xy auf die Playliste der nächsten Stunde an.
Das Script würde für die Elemente in dieser Playliste dann die Normalisierung triggern und das aktuelle Cue-Sheet importieren. Das mit dem Cue-Sheet hatten wir schon mal irgendwo angefangen aber da hatte ich noch Fehler drin.
Und ich wollte schon fragen, ob sich dahingehend etwas getan hat.
Ich würde gerne dieses Thema noch einmal hoch holen, ich möchte wirklich gerne unsere Wiederholungen und externe Zulieferungen komplett automatisieren und ein Kunde von mir könnte diese Funktion auch sehr gut gebrauchen.
@Torben hast Du da irgend eine Aussicht? Scheduled Events auf eine in der Zukunft geplaten Playliste z.B. was dann mein Cue-Sheet läd, die Länge neu ermittelt und die Lautstärke normalisiert?
Sorry, so lange ich hier den halben Tag Mathelehrer und Motivationscoach spielen muss, bleibt keine Zeit für solche Themen.
Aber für mich klingt das ohnehin so “custom”, dass es nach einem Script schreit. Denn die Anforderungen aller User (welche Elemente, wann und wie oft ausgeführt, was alles aktualisieren) wirst du mit einem generischen Feature kaum unter einen Hut bekommen.
Wo hakt es denn in Sachen Script-Lösung?
Daran, dass ich das nicht auf eine in der Zukunf geplante Playliste anwenden kann, bevor diese überhaupt in die aktive Stunde geladen wurde.
Ja doch, du kannst sie doch aus der DB laden, verändern, und in die DB zurückschreiben.
Oder alternativ das Element in der Bibliothek auf dieselbe Weise bearbeiten.
Das hört sich nach der besten Lösung an, da hänge ich nichtmal an einer Playliste. Hast Du da ein Beispiel?
Wäre auch eine Lösung für diesen Anwendungsfall, um es etwas dynamischer zu lösen.
Element 1234 aus der Bibliothek laden, Peak-Normalisierung durchführen, zurückschreiben:
var
item: IPlaylistItem;
begin
item := Database(0).CreatePlaylistItem('1234');
item.AsFile.Normalize(nmPeak, nil);
Database(0).SavePlaylistItem(item);
end.
Danke, das werde ich mal testen.
Ist das nur die Normalisierung oder auch das bestimmen der Peak Werte? Ich vermute ersteres. Also wenn keine Werte im DB Elemententafeln enthalten sind beides ansonsten nur Normalisierung auf Basis der gespeicherten Peak Werte?
Mir ist noch eingefallen, dass es früher mal so war, dass man die Elemente ohne Cue-Punkte in der DB Speicher und cue-in, Fade und cue-out dann beim Laden automatisch ermittelt werden. Das sollte ja noch so sein.
Quizfrage, wenn ich ein cue-sheet vorab lade, funktioniert das dann auch? Speziell cue-in und -out?
OK, ich kann meine Mutmassungen selber beantworten. Es macht genau das, was passiert wenn man auf den Normalize button klickt.
Ich brauche also noch die Analyse vorweg. Kann ich hier die Art der normalisierung wählen? Das scheint nicht TruePeak zu sein, was eigentlich meine default normalisierung ist.
Ich habe die letzte verfügbare Scripthilfe durchsucht aber ich finde so komplett gar nichts dazu.
Um dann das Cue-Sheet zu laden, kann ich einfach den Part aus @Tondose seinem Script dazwischen packen?
var
item: IPlaylistItem;
Cue: string;
begin
item := Database(0).CreatePlaylistItem('11317');
item.AsFile.Normalize(nmPeak, nil);
Factory.CreateMetadataHandler(Item.AsFile).ReadNativeTags;
Cue := IFilePlaylistItem(Item).GetFilename + '.cue';
Item.GetCueData.LoadFromCueSheet(Cue);
Database(0).SavePlaylistItem(item);
end.
EDIT:
Ja, ich kann.
Ich würde gerne bei dem Script noch etwas weiter kommen. Wie stoße ich denn ein erneutes einlesen der Peakwerte an und wie normalisiere ich auf TruePeak?
Außerdem würde ich sicherheitshalber abfangen wollen, den Fall, dass das CueSheet nicht existiert.