Vorrausgegangen hab ich dazu nur diesen Beitrag gefunden…
… in dem es lediglich um die Peripherie geht aber kaum um den Encoder selbst.
Problem ist, das viele und speziell ein bestimmter von manchen sehr geliebter Streamserver damit überhaupt nicht klar kommt. Gerade beim Thema Live Wechsel von Playlist Automation des Servers auf Live Sendung mittels mAirList kommt es dabei zu sehr unschönen Fehlern in der übertragung durch Sprünge, Aussetzer und Abbrüchen.
Daher die Frage:
Wer zieht die Kuh vom Eis bzw wer hat sie überhaupt aufs Eis geschickt???
Hat das einen bestimmten Grund?
Ist das der aktuelle “Rundfunk-Standart” in der Übertragungstechnik auch im Internet?
Würde mich mal interessieren. Schönes Wochende zusammen.
Gute Frage, jedoch bezieht sich diese Einstellung auf die Encoder-Übertragungseinstellung selbst und eben nicht bzw. unabhängig von der verwendeten oder nicht verwendeten Audiohardware.
(Beispielbild stammt aus Windows Server ohne Audio)
Daher hatte ich mich ein wenig gewundert weshalb gerade dort 48000 Hz als Voreinstellung eingetragen ist.
Während man bei Mikrofonen etc ja durchaus mehr Sampling Sinnvoll verwendet, besteht ein Musiktitel von CD ja auch nicht mehr als aus 44100 Hz Samplerate. (Abgesehen von anderen Faktoren wie Bitrate und Bittiefe)
Auch wenn ich von den Mechanismen nicht viel Ahnung habe, kann ich mir nicht vorstellen das eine höhere Abtastrate einer Audiodatei die ohnehin nur 44100 Hz beinhaltet, eine Klang oder Qualitätsverbesserung bietet oder? Wo nichts ist, kann auch nichts hinzugebastelt werden. Ergo auch nicht bei einen Signal das neu encodiert wird.
Es ist richtig, dass die Samplerate im Encoder seit v7 standardmäßig auf 48 kHz steht. Wer seine Konfiguration aus v6 oder v5 überimmt, behält natürlich die bisherigen Einstellungen bei, so eben auch die bisherige Samplerate von 44,1 kHz.
Dies kann, wie schon seit jeher, jederzeit angepasst werden:
Generell, in den Optionen (siehe Screenshot oben),
in jedem einzelnen Encoder selbst.
Zu deinen Fragen kann Torben die Hintergründe erläutern. Er hat’s reingebastelt. Ich finde es gut, habe es getestet und keinerlei Artefakte oder Probleme feststellen können.
Dass es beim Wechsel zwischen Moderatoren oder der Automation von 44,1 und 48 kHz zu reconnects kommen kann, ist ein unschöner Nebeneffekt, ja.
Nein, in diesem Fall wird nicht die Soundkarte abgefragt. Das würde sonst in einigen Fällen zu aberwitzigen Sampleraten von 96 bis zu 192 kHz führen.
Mikrofone haben eine Samplerate?
Tja, das wird philosophisch. Es besteht durchaus Einigkeit, dass der OPUS-Codec eine hohe Qualität liefert und für Verbindungen zwischen Studios eingesetzt werden kann, aber auch für ganz profanes VoIP (Studio Link, dann TeamSpeak, soweit ich weiß und vermutlich auch Skype).
Dieser Codec ist fest auf 48 kHz eingestellt. Wenn du also mit dem streamst (manche Radios machen das), hast du gar keine Wahl. Stört merkwürdigerweise aber auch keinen.
Tja, dann erzähl’ das mal bitte den Sendern, die einen 192-kbps-Stream in die Welt senden, in ihren Archiven bzw. Rotationen aber meist nur 128er Mp3s oder AACs liegen haben. Und das wird dann mitunter als “HD-Stream” verkauft.
(LautCast) Schlimmer noch, die übertragung an sich spielt komplett verrückt. Nun gut, das ist zunächst nicht wirklich die Schuld von mAirList das es zu Aussetzer, sprüngen, repeats und Abbrüchen seitens des Servers kommt jedoch wissen wir ja auch das gerade bei Laut viele mAirList verwenden. (Oder es auch in Zukunft vor haben)
Daher jetzt ja der Ansatz:
Die Mikrofone nicht aber dessen AD Wandler in Form von Audiointerfaces usw… Das sollte doch klar sein.
Das hat alles nichts damit zu tun das der Übertragungsweg, und nur darum geht es hier, vom mAirList Encoder zum Server nun Standartmäßig auf 48 Khz gestellt ist. Was davor geschieht, sei es ein Interview, ein Lied oder sonst was mit utopischen Bitraten, Samplingraten und Bittiefen ist in diesem Fall irrelevant denn im Encoder geht alles als PCM Signal zusammen. (So hab ich das mal verstanden, bitte um Korrektur falls ich mich irre) Dafür wäre es gut zu wissen weshalb das nun so ist.
Das das Quatsch ist, ist klar.
Dennoch: Sollte man nicht statt dessen den gemeinsamen kleinsten Nenner definieren und nicht einen Mittelweg nutzen?
Deshalb die Frage:
In dem Fall das Material das zu 90% der Stunde zählt? - die Musik von CD
Und wie wir alle wissen stammt aus dieser Musik eine Samplerate von 44100 Hz und eben nicht 48000 Hz. Abgesehen von den Serverproblemen die hervorgerufen werden, hört niemand den Unterschied. Außer man möchte nun einen Samplerate War entfachen.
Gilt das denn dann auch für alle erdenklichen Server Anwendungen und Empfangsgeräte wie WLAN Radios usw?
Ich habe es so gelernt, das wegen der verlustbehafteten Übertragung durch MP3 möglichst eine hohe Ausgangsqualität vorraus gehen soll.
Also alles was noch vor dem Encoder statt findet sollte besser sein als das encodierte Endsignal. Das leuchtet ja auch ein aber um diese Peripherie geht es ja gar nicht.
Naja hätte mich eben interessiert, ob es dazu gewisse Standarts zwischen Encoder und Server gibt.
Bis dahin kenne ich ja nun die Fehlerursache bei Streamabbrüchen zwischen mAirList und einem Server wegen voreingestellter 48000 Hz (zumindest beim LautCast)
Grundsätzlich (!) gilt, dass du im Encoder bitte das einträgst, was serverseitig erwartet wird.
Punkt.
Die globalen Encodereinstellungen sind das eine, die spezielle - je Encoder - das andere, und auch hier gilt: Die Einzel-Einstellung “gewinnt”. Du kannst also mit 44,1 kHz auf den Server streamen und deine eigene Aufzeichnung mit 48 kHz vornehmen.
Integrierter Streaming-Server (mAirList innerhalb des LAN auf verschiedene Endgeräte und unterschiedliche Abhören, inkl. Aufzeichnung durch den mAirList Audio Logger),
Externer Icecast, der mir zu Testzwecken freundlicherweise zur Verfügung gestellt wurde.
Aktuell sende ich auf einem Shoutcast v1 mit 44,1 kHz (weil Vorgabe, siehe oben), könnte das aber sicher ebenso gut mit 48 kHz machen. Vielleicht nötige ich mal den Tester mit einem Kollegen zu entsprechenden Switchen.
In meinen nun über 16 Jahren Webradioszene habe ich gelernt, dass es fast nichts gibt, was unmöglich erscheint.
Unvergessen der Moderator, der sein Großmembran-Mikrofon axial ansprach, weil es eben genau so in der Verkaufsabbildung zu sehen war und sich keineswegs über den doch sehr merkwürdigen Sound wunderte. Er hat sich damit sogar einem öffentlichen Aircheck gestellt.
Sorry, @TomJumbo83, aber in manchen Bereichen wundert mich nun wirklich gar nichts mehr und dann stelle ich auch mal eine vermeintlich blöde Rückfrage.
Encoder entweder im einzelnen auf 44100 stellen oder generell in den Encoder-Optionen. Immer dran denken, der einzelne Encoder mit seinen Einstellungen hat Vorrang.
Abgesehen davon, dass ich gar nicht wusste, dass es einen “LautCast” gibt.
Na gut, bitte. Wieder was gelernt. Der kann also keine 48 kHz, interessant.
Ich stimme zu, dass eine CD mit 44,1 kHz beim rippen nicht resampled werden sollte.
Bei einer DVD wären es 48 kHz.
Landet alles im Archiv.
Ein Interview mit dem Pocketrecorder kommt mit 48 kHz wav rein, die Nachrichten als 44,1 kHz-mp3-Datei.
Überhaupt lege ich dir (und allen anderen) den gesamten Thread, in dem du dich schon sehr engagiert hast, als erneuten Lesestoff ans Herz (mAirList Samplerate), ebenso wie den im EP von dir bereits erwähnten.
Zugegeben, auch wenn wir alle wissen wie das läuft, ist das eine spezielle Anwendung die nicht Mal eben auf GitHub oder sonst wo zu beziehen ist. Es ist eine Eigenentwicklung von LautFM für dessen generellen Betrieb.
Ich fragte mich einfach nur, welchen Grund das nun hat das mAirList in der Grundeinstellung auf 48000 Hz ausgeliefert wird.
Letzt endlich ist es mir ja egal denn ich hab die Ursache nun benannt, weshalb es in der V7 in Verbindung mit LautFM zu massiven Problemen kommt. Das wars
Auf jeden Fall danke ich dir dafür, dass du diese Konstellation erwähnt hast.
Ich werde nachher auf den Shoutcast-Testserver gehen, den ich nutzen darf, und hier mal einen “Stresstest” mit 48 kHz durchführen. Mal sehen, wie leicht der das schluckt.
Bei einer Zufalls-Stichprobe ist mir aber noch was anderes aufgefallen: Die öffentlich-rechtlichen Webstreams scheinen alle mit 48 kHz ausgesendet zu werden.
Leider wird unter “Empfang” der Opus-Stream nicht ausgewiesen, dass ich ihn im externen Player hätte auslesen können. Aber dass bei OPUS 48 kHz genutzt werden, dürfte klar sein.
Resümee der Stichprobe: Es gibt keinen Standard, höchstens eine Mehrheit.
Interessant!
Wer seine Konfiguration aus v6 oder v5 überimmt, behält natürlich die bisherigen Einstellungen bei, so eben auch die bisherige Samplerate von 44,1 kHz.
:
