Ich möchte gerne das klassische Webradio-Setting installieren, bestehend aus einem zentralen 24/7 Playout mit Mairlist. Verschiedene Außenstudios und/oder DJs sollen dieses Programm für Live-Übertragungen unterbrechen können. Hier käme also der Sreaming Monitor und der Encoder zum Einsatz.
Bei dieser Lösung frage ich mich allerdings, wie es mit der Qualität aussieht, die am Ende beim Hörer ankommt. Nehmen wir dabei folgendes an:
Ein DJ streamt mit seine .flac-Files mit 192 kbit/s mp3 via privatem Icecast-Stream zu Mairlist über den Streaming Monitor. Dieser übernimmt den Stream und gibt ihn über den Encoder an den öffentliche Icecast-Server weiter, sagen wir mit einer Qualität von ebenfalls 192 kbit/s mp3.
Wenn ich es richtig verstehe, kommt beim Hörer dann ein 192 kbit mp3-Stream an, der zuvor bereits schon eine Transcodierung hinter sich hat, sprich: die mp3-Artefakte werden durchs zweifache Encodieren verstärkt, korrekt?
Nehmen wir weiter an, die 24/7 Automation würde ebenfalls mit .flac-Files arbeiten. Hier würde das Signal direkt via des Encoders an den öffentlichen Icecast-Server mit 192 kbit/s mp3 geschickt. Hieße, wir hätten hier lediglich eine Codierung und damit eine bessere Qualität.
Unterm Strich hätten Liveübertragungen damit automatisch immer eine schlechtere Qualität als die Automation.
Sehe ich das soweit richtig? Und wenn ja, gibt es Empfehlungen, mit welchen Einstellungen man dieses Problem mindern kann? Wie läuft das bei Livebroadcasts über LiquidSoap, wird hier auch der DJ-Stream erneut encodiert oder wird dieser direkt an den Hörer weitergeleitet?
Wenn ich das richtig verstehe, fürchtet Marco eine Verschlechterung des angelieferten Signals durch eine erneute Encodierung.
Schlechter = nicht so gut wie das ankommende Signal bzw. das der Automation gleicher Qualität.
Mit dieser Frage oder dem Thema habe ich mich in der Vergangenheit auch schon beschäftigt.
Bei mir jedoch kam noch Sound-Processing von Stereotool dazu.
Zu meiner persönlichen Erfahrung:
Dabei könnte man jetzt wieder eine Diskussion vom Stapel lassen, was eine gute oder bessere Qualität sein soll. Also ab welchen Kilobitzahlen oder Kompressionsverfahren das Signal nun gut oder besser ist…
Ich für meinen Teil hab die Automations Musik selbst, stets in 320 kbps mp3 vorliegen. (Quelle Original CDs mit Flac archiviert) Was aber daran geschuldet ist, das auf einem Windows Server der Speicherplatz meist nicht so üppig ausfällt als auf einem stationären Rechner.
Gesendet wurde das Endsignal zum Hörer als 192 kbps mp3.
Was zwar zunehmend weniger das Problem wird jedoch dennoch im Hinterkopf behalten werden sollte bei Servern, sei es nun der Stream Server selbst oder mAirList (Windows) Server ist der Traffic der monatlich anfällt. Also für den Dauerbetrieb als auch für die “Zulieferung” der Moderatoren.
Daher hab ich mich damals mittels AzuraCast dazu entschieden, die Moderatoren per HE AAC Plus 192 kbps senden zu lassen.
Die einen sagen, das mehr als 160 kbps mp3 keinen hörbaren Qualitätsverlust bietet, die anderen sagen das das Gegenteil. Insbesondere dann, wenn Sound-Processing noch in der Kette vorhanden ist, sollte man zumindest nicht schlechter* als das Endsignal zuliefern.
AAC soll allgemein in höheren Bitraten wesentlich weniger Qualitätsverlust bieten als mit vergleichbaren kilobit Werten mit MP3. Bin aber kein Experte darin.
Meine Annahme mit .flac-Files als Musik-Quelle ist dabei noch sehr optimistisch.
Man stelle sich vor, die Musik des DJs würde als .mp3-File vorliegen, was wohl in den allermeisten Fällen immer noch zutrifft. Dann hätten wir bereits an der Quelle Codierungs-Artefakte, die durch die zwei weiteren Codierungen verstärkt würden bzw. neu hinzukommen. Also:
Musik-Quelle mp3 (1. Codierung) → Icecast-Stream zum Streaming Monitor (2. Codierung) → Stream zum Icecast-Hörer-Stream (3. Codierung).
Zur Veranschaulichung: das ist in etwa so, als wenn man einen Song als mp3-File rippt und ihn noch zwei weitere Male als mp3-Datei neu abspeichert. Es kommen immer weitere Artefakte hinzu und sind schon beim zweiten Codieren für ungeschulte Ohren deutlich wahrnehmbar. Es handelt sich also um massive Veränderungen des Signals.
Um das zu minimieren könnte man ja vorschreiben, dass die DJs
nur MP3 mit 320kb/s nutzen dürfen, die in guter Qualität umgewandelt wurden
auch in 320kb/s zum mAirlist-Streammonitor senden, selbst wenn der Encoder dann die Ausgangsqualität für den Hörer reduziert
Wie @TomJumbo83 schon schrieb, sollte die anliefernde Qualität definitiv nicht schlechter sein als der Stream, der beim Hörer ankommt. Ich würde sogar sagen: Immer eine Stufe besser. Aber das hast Du ja auch durch Dein Beispiel der mehrfachen Speicherung schon beschrieben.
All das ließe sich aber auch leicht testen, indem Du die verschiedenen Streams anlegst und schaust, was beim Hörer danach ankommt und ob es Deinen Ansprüchen genügt…
Zweifelsohne. Ich hätte „Verschlechterung“ aber gerne quantitativer beschrieben bekommen.
(Spoiler: Die Wiedergabequalität wird bei den genannten Parametern nicht hörbar verschlechtert. Insbesondere, wenn man das Wesen der in der Regel gestreamten Progamminhalte berücksichtigt.)
Ich würde diese Quantifizierung gerne liefern, glaube aber nicht, dass sie ohne weiteres möglich ist.
Wir sprechen hier ja hier immerhin über verlustbehaftete Audioformate und damit über psychoakustische Aspekte. Diese bei bestimmten Konstellationen mit bestimmten Bitraten zu quantifizieren erfordert sicherlich einen wissenschaftlichen Hintergrund. Ansonsten verbleibt der subjektive Höreindruck.
Deshalb würden mich Eure Erfahrungen interessieren, mit welchen Codecs und Einstellungen derartige Effekte minimiert werden können. Danke schon mal an @Stefan_Hillen und @TomJumbo83.
Korrekt. Wenn man es weiß, ist die Qualität natürlich gleich scheinbar schlechter. Ich postuliere: Die Unterscheidung vorher/nachher wird einem A/B-Vergleich nicht standhalten.
Die ersten vermeidlichen Artefakte können schon vorhanden sein anhand der Quelle der Musik die der Moderator verwendet, das ist richtig. Je nach Komprimierungsverfahren und oder Quellen der Musik kann es hier schon scheitern.
Als nächstes steht die Encodierung durch den lokalen Encoder des Moderators an. Hier könnten theoretisch die nächsten Artefakte entstehen.
In deiner Erklärung sprichst du von Transcoder auf dem IceCast Server. Also würde hier das nächste Artefakt dazu kommen können.
Im Stream Monitor angelangt und ausgespielt passiert das Signal den endgültigen Encoder der 24/7 Automation zum IceCast Live Server. Wieder Artefakte die dazu kommen
ggf. soll der Hörer noch einen “Mobil Stream” angeboten bekommen was eine weitere Transcodierung nötig macht. Und hier spielen die Artefakte dann komplett verrückt.
Ist das wirklich so?
Ich glaube nicht. Dahingehend kann ich dich beruhigen wenn du von vornherein gewisse Spielregeln deinen Moderatoren und Techniken in den Signalwegen beachtest.
Das erste was mir aufgefallen ist als ich deinen Beitrag gelesen habe war das war Wort: Transcoder
Hier haben wir nämlich in Kombination von IceCast und dem Stream Monitor das erste Problem was es technisch nicht möglich macht überhaupt den wechsel zwischen 24/7 Playout und Livesendung zu realisieren.
Der Stream Monitor kann nur erkennen ob eine Quelle Online oder Offline ist. Ergo, ob ein Streamserver sendet oder nicht. Verwendest du nun einen Transcoder in IceCast, der auch für die DJ Verwaltung (PW etc.) zuständig ist, hat das den Nachteil, das dieser Serverstream daueronline ist. Wenn kein Moderator verbunden ist, wird Stille gesendet und der Streammonitor erkennt nicht das kein Moderator da ist um wieder auf die Automation im PlayOut um zu schalten sondern sendet ebenfalls die ankommende Stille.
Die Lösung ist also keinen Transcoder auf dem IceCast ein zu setzen.
Vorteil:
Das hat den positiven Effekt das durch den fehlenden Transcoder das Signal des Moderators auch nicht weiter auf dem Server bearbeitet wird sondern nur weitergeleitet und kein Qualitätsverlust statt findet.
Nachteil:
Jede externe Quelle, Moderator braucht theoretisch seinen eigenen (nicht öffentlichen) Streamserver oder alle Moderatoren haben die selben Zugangsdaten des Servers inclusive des Passwortes.
Fangen wir mal beim kleinsten Nenner also an:
Die Quelle der Musik beim Moderator sollte die bestmöglichste sein.
Die Übertragungsqualität im Encoder des Moderators sollte möglichst verlustfrei eingestellt sein. Ich persönlich habe wie oben schon erwähnt mit 192 kbps HE AAC+ gute Erfahrungen gemacht. (Nicht offiziell von mAirList unterstützt)
Der IceCast Server ohne Transcoder gibt das Signal weiter an den den eingerichteten Stream Monitor von 24/7 mAirList und überlagert das PlayOut
ggf. kann noch Sounprocessing im endgültigen Encoder enthalten sein wie StereoTool etc.
Der endgültige Encoder sollte auch die letztendliche Qualität zum öffentlichen Streamserver senden mit denen die Hörer auch verbunden werden. Oder das Signal in die Welt verteilt wird.
Der öffentliche Streamsever bereitet ebenfalls kein Signal mehr auf da auch hier kein Transcoder verwendet werden sollte.
Selbst wenn der öffentliche Streamserver über einen Transcoder verfügt um bspw. aus dem Master Sendesignal noch einen Mobilstream anbieten zu können, ist das nicht weiter schlimm solange die bestmöglichste Qualität die der Hörer bekommen kann, bereits von mAirList zum Server gesendet wird.
Somit haben wir genau zwei Punkte an denen es zu Artefakten kommen könnte, insofern die Quelle der Musik einwandfrei ist.
Encoder Moderator
Encoder 24/7 mAirList zum Streamserver
Stellst du hier die Ansprüche bereits sehr hoch, solltest du keinen Unterschied zwischen der Flac Automation und den live Sendungen der Moderatoren feststellen können.
Soweit verstanden. Mit einer winzigen Korrektur: Statt
muss es, ganz penibel, heißen:
via seinem mAirList Encoder auf unseren Icecast in der Automation, auf den der Stream Monitor “hört”.
Der Moderator daheim braucht keinen eigenen Icecast, sondern nur eine IP plus Mountpoint als Ziel. Und den hast du ja in der Empfangszentrale aufgesetzt.
Streng genommen: Ja.
Allein, dafür brauchst du Goldohren. Wenn ich bei typischen Webradios wirklich Artefakte höre, dann kommen sie in aller Regel von einem schlechten Rip oder ich merke ein besch… Soundprocessing beim Moderator. Der doppelte Encoder hat mir (zumindest bei den Radios, die diese Technik anwenden) noch nie in den Ohren weh getan.
Auch das ist, rein theoretisch, korrrekt.
Allerdings möchte ich mich @Tondose anschließen:
Deine Schlussfolgerung, dass die
… hätten, würde der Praxis nicht standhalten. Vor allem dann nicht, wenn du vom Moderator zum Stream Monitor die bestmögliche Qualität nutzt. Und jetzt treibe ich es mal auf die Spitze:
Du verwendest zur Zuführung zum Sender den OPUS Codec. Blöderweise macht der es nun mal (ganz automatisch) “nur” mit 48 kHz. Hilfe, Resampling!
Noch eine Baustelle mehr?
Spoiler: Du wirst es nicht hören.
In meinem Einzugsgebiet kann ich den hessischen Rundfunk (hr) hören, und dessen Stream kommt z.B. bei hr1 als mp3 | 128 kbps | 48 kHz hier an. Vollkommen problemlos und ohne hörbare Störungen (von einem miesen loudness range mal abgesehen).
Gut, vielleicht liegen die Dateien dort bereits mit 48 kHz im Archiv, aber irgendwo muss das ja auch her kommen.
Du könntest die Zuführung zum Stream Monitor natürlich auch mit flac kommen lassen, allerdings weiß ich da gerade nicht, wie es mit den Metadaten aussieht (bei OPUS geht es vermutlich nicht, wenn ich es richtig im Kopf habe).
Und wenn es schon bestmöglich im MPEG-Bereich sein soll, kannst du auch mp2 | 384 kbps nutzen (Lizenzbestimmungen beachten).
Ersteres. Am Ende steht immer wieder ein Encoder.
Jetzt noch ein paar Fundstücke aus dem Thread.
Tja, wenn der Speicherplatz auf dem Server der Flaschenhals ist, dann ist das tatsächlich eine Alternative.
An komplett anderer Stelle habe ich mal Vergleiche angestellt: Hier und hier.
Wobei ich in dem Fall vermutlich auf mp2 umgestiegen wäre. Das ist aber was persönliches, weil ich gleich zu Beginn meiner DJ-Zeit mit mp2 gearbeitet habe und nur Goldohren hören hier tatsächlich geringfügig bessere Details speziell in den höheren Frequenzen (Song-Intros mit Piano-Solo z.B.).
Jein.
Zunächst mal sind es nur zwei Eingriffe, nicht drei (Encoder des Moderators und Encoder des Senders) und das halte ich für vertretbar.
Das von dir beschriebene Phänomen kenne ich auch, und tatsächlich deutlich hörbar, aber das trat nach zwei Spreichervorgängen, abgehört auf einer amtlichen PA, noch nicht auf. Erst später.
Hintergrund: Karneval, Gardetanz, Korrekturen im Sekundenbereich, Kürzung des Einmarschs nach der x-ten Probe. Die haben immer die letzte geschnittene Version in Audacity geschmissen und neu als mp3 gespeichert statt eine Arbeitskopie des verlustfreien Masters neu zu schneiden und gewissermaßen erstmalig zu exportieren.
Ich rate daher dazu, die Kirche im Dorf zu lassen.
Anhand der Quelle? Bei einem guten Radio (kein “Webradingens™” bzw. “Bumsbude”) steht als Quelle sowieso nur die eigene CD zur Verfügung, und wenn die Dateien schon als *.flac´ vorliegen, sehe ich da keine Probleme.
An welche anderen - legalen! - Quellen denkst du sonst noch?
Den sehe ich zwischen dem Moderator und dem Stream Monitor überhaupt nicht.
So nebenbei:
Ich habe jetzt die Suchfunktion F3 auf den Begriff in dem Thread angeworfen, und bevor du das Wort hier eingeführt hast, hat keiner etwas dazu geschrieben, auch Marco nicht in der Form.
Habe ich etwas übersehen?
Wenn du dich hierauf beziehst:
(Hervorhebung von mir)
… dann könntet ihr möglicherweise aneinander vorbeigeschrieben haben. Würdet ihr beide das bitte noch einmal abgleichen, bevor ich eine vollkommen aus dem Ruder laufende Diskussion wieder einfangen muss?
Könnte ja sein, dass Marco den Begriff anders gemeint hat, als Tom ihn aufgefasst hat.
Das könnte durchaus sein. In Verbindung mit IceCast Server ist mir das eben so geläufig.
Wobei wir beim mAirlist ja nicht Transcodieren also Umwandeln, sondern Encodieren und das einzig und allein im Encoder daher vermutlich meine Fehlinterpretation.
Gerade hab ich auch gesehen das @MarcoS ja terrestrisch sendet. Davon hab ich natürlich gar kein Plan was daran noch alles hängt denn ich selbst bin ja nur einer von den
24/7? Sicher?
Abgesehen davon, ich glaube, seine Frage drehte sich um reines Streaming. Sonst wäre der zweite Encoder im “Main mAirList” doch gar nicht notwendig. Das terrestrische Signal würde das Pult direkt verlassen. Über einen Fader läuft die Automation - oder eben die High-Priority Live-Übernahme per Stream Monitor.
Vorschlag: Konzentrieren wir uns besser auf den reinen Stream, wie von Marco zu Beginn beschrieben.
Das ist deine Eigenwahrnehmung. Ich kenne weder dein Radio noch deine Ansprüche.
Was ich meine, sind Radios, denen weder Herkunft der Musik, noch Qualität, noch Pegel etwas bedeuten und deren “Modis” sich weder live noch hinterher monitoren. Derer gibt es reichlich.
Erstmal will ich sagen: ihr habt alle irgendwie Recht.
Wir senden zehn Tage im Jahr terrestrisch. Zusätzlich soll es bald ein reines 24/7 Webradio mit einzelnen Live-Shows geben. Neues Terrain sozusagen. Meine gesamte Anfrage bezog sich ausschließlich darauf. Beim terrestrischen Funken dagegen geht unser Signal direkt vom Mischpult mit einem einzigen Encodier-Vorgang zum Icecast.
Jein.
Zunächst mal sind es nur zwei Eingriffe, nicht drei (Encoder des Moderators und Encoder des Senders) und das halte ich für vertretbar.
Wenn man ganz penibel sein will, dann zählt man ehrlicherweise den Encoder beim Erstellen der mp3 mit. Deshalb kam ich hier auf drei Eingriffe. Wenn das Musikarchiv aus .flac-Dateien besteht, sind es tatsächlich nur zwei Eingriffe (Encoder Moderator, Encoder Sender). Letzteres trifft auf meinen Fall zu.
Ich denke, ich habe schlicht den Begriff “Transcodieren” falsch gebraucht und meinte damit tatsächlich das zweifache Encodieren, wobei das ja an den zwei vorbenannten getrennten Stellen der Signalkette geschieht und weder alleine in der Mairlist 24/7 Maschine, noch an meinem Icecast. Der soll natürlich nicht transcodieren, das wäre dann wirklich zu viel des Encodierens.
Du könntest die Zuführung zum Stream Monitor natürlich auch mit flac kommen lassen, allerdings weiß ich da gerade nicht, wie es mit den Metadaten aussieht (bei OPUS geht es vermutlich nicht, wenn ich es richtig im Kopf habe).
Das scheidet leider aus, da ich die hierfür nötige Bandbreite seitens der DJs für unzumutbar hoch halte. Opus wäre somit aus qualitativer Sicht mein Favorit., evtl. auch MPEG2. Immerhin hat man mit diesem früher sogar bei deutlich niedrigeren Bitraten gearbeitet (128 kbit/s mit ISDN) - und das sogar bei terrestrischen Übertragungen.
Ja, ja, ja. Vielleicht mache ich mir zu viele Gedanken und freunde mich hiermit an
Ich rate daher dazu, die Kirche im Dorf zu lassen.
ohne jetzt komplett Formate und Einstellungen aus dem Blick zu lassen.
Unterm Strich habe ich gelernt: wenn ich eine Automation mit Liveübertragungen realisieren möchte, komme ich ums doppelte Encodieren nicht herum, egal ob mit Mairlist oder LiquidSoap. Das hat etwas Beruhigendes, da ich am liebsten auch für die Webradio-Automation Mairlist einsetzen möchte
Nun ja, warum sollten hunderte (tausende?) Webradios das sonst genau so machen und auch mit dem Stream-Monitor arbeiten? Du wärest ja sicher nicht der Erste/Einzige, dem ein guter Klang wichtig ist…
Da haben wir ihn ja, den Transcoder. Liquidsoap ist ein sehr mächtiges und umfangreiches Tool das bspw in AzuraCast gute Dienste leisten kann.
Wie ich schon gesagt hatte:
Das bezieht sich aber nur auf die Schnittstelle zwischen Moderator und Streammonitor.
Eben für diesen Fall bietet es sich an, sich einen eigenen AzuraCast Server zu erstellen. In diesem kann man, wenn man möchte, zig einzelne Mountoints ohne “AutoDJ” und Transcoder unabhängig von einander und nicht öffentlich anlegen. Diese können dann jeweils im Stream Monitor mit unterschiedlichen Prioritäten eingepflegt werden.
Dabei ist es dem AzuraCast Mountpoint dann egal mit welchem Signal, also welchem Codec, man dann ankommt als Moderator. Er leitet das weiter was geliefert wird an denjenigen der daran lauscht. In unserem Fall der Stream Monitor.
Ich bin momentan auch der Meinung das Opus keine Meta Daten mit sendet.
Qualitativ wäre das eine Hausnummer auch in Hinsicht auf den Traffic und Latenz da Opus schon mit sehr niedrigen Bitraten gute Ergebnisse liefert.
Noch eine kleine Ergänzung zu Liquidsoap in AzuraCast am Rande.
Da bei mir bspw, neben Liquidsoap auch noch Stereotool in AzuraCast läuft, es sich aber in meinem Fall um den Hörer Endpunkt Mounpoint handelt und nicht die Schnittstellen zum Stream Monitor, ist eine Interessante Sache noch zu wissen:
Stellt man die Transcodierung mittels LS dann ein um auch bspw eine Fallback Automation in AzuraCast noch zu haben, sind die Transcodierungs Parameter ja festgelegt: Also fürs die Fallback Automation von AC selbst und für einkommende Quellen. Bspw definiert 196 kbps mp3.
Sende ich dann doch mal live mittels mAirList und ist der Encoder ebenfalls auf 196 kbps mp3 eingestellt, passiert im Transcoder von Liquidsoap folgendes: Gar nichts.
LS erkennt die ankommenden Quellen und weichen diese nicht von den Voreinstellungen für den Hörer Mountpoint ab, wird auch nichts daran verändert.
So kann kann man zumindest davon aus gehen, das hierbei an diesem Punkt auch keine Verluste mehr entstehen. Der Einsatz von LS im Hörer Mountpoint macht trotzdem Sinn da die vorliegende Musik der Fallback ja auch unterschiedliche Dateiformate und Codierungen haben kann.
Aber das nur am Rande. Wie immer gilt das ich mich aber auch im Detail täuschen kann.
Sehr richtig! Es handelt sich also um eine grundsätzliche Fragestellung, die mit mAirList gar nichts zu tun hat.
Und wenn Du (angenommermaßen) was von Schallplatte sendest? Das ist aus Sicht des Masterbandes ein viel gruseligerer Schallspeicher mit Unmengen an Artefakten, insbesondere Rumpeln unKnacksen. Und selbst das Masterband ist aus Sicht der Studioabmischung schon erheblich verändert. Und jene ist aus Sicht des Musikinstrumentes … lassen wir das.
In diesem Zusammenhang fällt mir diese nette Zeichnung ein:
Hilfe, Resampling!
In Verbindung mit IceCast Server ist mir das eben so geläufig.
