webradio aufnehmen

[Codehunter]

Zitat von einbeliebigername:

Du musst nur das Problem lösen, dass vermutlich die Abspielgeschwindigkeit nur annähernd gleich der Datenanlieferung ist.

Wenn man genauer darüber nachdenkt, stellt sich dieses Problem eigentlich nicht. Bei einem Webradio-Stream hat man eine durch den Codec definierte Bitrate. Da könnte der DSL-Anschluss schnell sein wie er will, mehr als diese Bitrate käme dann nicht an. Auch BASS.DLL würde genau mit dieser Bitrate abspielen. Die Kunst wäre in diesem Fall eigentlich nur, vor dem Start der Wiedergabe einen Vorlaufpuffer abzuwarten.

Der umgekehrte Fall dürfte erfahrungsgemäß kritischer werden: Der Datenstrom kommt langsamer an als für den Codec erforderlich. Was nicht da ist kann man nicht abspielen, also gibts Lags. Da müsste ich dann sehen dass in dieser Situation ein automatischer Restart der Wiedergabe erfolgt wenn wieder Daten in den Puffer geflossen sind.

[einbeliebigername]

Hallo,

Zitat von Codehunter:

Zitat von einbeliebigername:

Du musst nur das Problem lösen, dass vermutlich die Abspielgeschwindigkeit nur annähernd gleich der Datenanlieferung ist.

Wenn man genauer darüber nachdenkt, stellt sich dieses Problem eigentlich nicht. Bei einem Webradio-Stream hat man eine durch den Codec definierte Bitrate. Da könnte der DSL-Anschluss schnell sein wie er will, mehr als diese Bitrate käme dann nicht an. Auch BASS.DLL würde genau mit dieser Bitrate abspielen. Die Kunst wäre in diesem Fall eigentlich nur, vor dem Start der Wiedergabe einen Vorlaufpuffer abzuwarten.

Der umgekehrte Fall dürfte erfahrungsgemäß kritischer werden: Der Datenstrom kommt langsamer an als für den Codec erforderlich. Was nicht da ist kann man nicht abspielen, also gibts Lags. Da müsste ich dann sehen dass in dieser Situation ein automatischer Restart der Wiedergabe erfolgt wenn wieder Daten in den Puffer geflossen sind.

Wenn man sich das genau überlegt, ist Bitrate irrelevant. Sie resultiert ja nur aus der Komprimierung der Audio-Daten. Ich betrachte jetzt mal einen wirklichen Livestream, wo noch ein Mensch sein bestes in Mikrophon gibt. Dann hast du beim Sender einen Analog-Digital-Wandler, der, durch einen Quarz getaktet, einen Datenstrom erzeugt. Auf der Empfangsseite hast du einen Digital-Analog-Wandler, der, durch einen Quarz getaktet, diesen Datenstrom in analoge Signale umwandelt. Die beiden Quarze sind nicht die Selben. Deren Frequenz ist nicht bis auf die milliardste Stelle gleich. Einer von beiden geht mit großer Wahrscheinlichkeit langsamer. Und wenn das der beim Empfänger ist, stauen sich irgendwo da zwischen die Daten.

Mir passiert das beim Radio hören über Web regelmäßig. Entweder gibt es kurze hörbare Aussetzer, dann war mein Rechner mal wieder schneller, oder der Versatz zwischen Analog-Radio und Web-Radio wird immer größer. Das einzige was da helfen konnte, währ wenn die Bass.dll den Quarz am DA-Wandler justieren könnte, und somit die Widergabegeschwindigkeit an den Sender angleichen könnte. Aber ich glaube das geht bei keiner Consumersoundhardware, weil dann könnte Winamp das auch.

einbeliebigername.

[Sherlock]

Das glaube ich so gar nicht. Gründe für Aussetzer sind eher irgendwo auf der Verbindungsstrecke zu suchen, als in irgendwelchen "Quarzen". Man sollte nicht vergessen, daß TCP/IP eine Verbindung über viele Zwischenstellen aufbaut.

Sherlock

[einbeliebigername]

Hallo,

Zitat von Sherlock:

Das glaube ich so gar nicht.

Der Gangunterschied von Quarzen ist ein physikalischer Fakt. Den kannst du glauben oder nicht, der ist einfach da. Wer noch Quarzuhren kennt kann das bestätigen.

Zitat von Sherlock:

Gründe für Aussetzer sind eher irgendwo auf der Verbindungsstrecke zu suchen, als in irgendwelchen "Quarzen". Man sollte nicht vergessen, daß TCP/IP eine Verbindung über viele Zwischenstellen aufbaut.

Das wollte ich nicht ansprechen. Macht es nur noch komplizierter und schränkt die möglichen Lösungen ein.

einbeliebigername.

[p80286]

Zitat von einbeliebigername:

Der Gangunterschied von Quarzen ist ein physikalischer Fakt. Den kannst du glauben oder nicht, der ist einfach da. Wer noch Quarzuhren kennt kann das bestätigen.

unbenommen, doch welche Auswirkung hat das in der praktischen Anwendung?
Wenn meine Quarzuhr nur für's Eierkochen genutzt wird, gar keine, wenn ich die Ganggenauigkeit über ein Jahr messe, dann wie viele Sekunden?

In diesem konkreten Fall ist da eher die Datenlieferung über das Netz der primär einschränkende Faktor.

Gruß
K-H

[einbeliebigername]

Hallo,

Zitat von p80286:

Wenn meine Quarzuhr nur für's Eierkochen genutzt wird, gar keine, wenn ich die Ganggenauigkeit über ein Jahr messe, dann wie viele Sekunden?

So einen Webstream spielt man ja mitunter nicht nur 5 Minuten (Ich hab es auch schon mal auf mehrere Tage gebracht). Und mir ist es schon mehrmals aufgefallen, dass aus dem anfänglichen 30s Versatz in einer Stunde ohne Aussetzer über ein Songtitel wurde. Es ist klar, dass es nicht die Regel ist. Was ich damit nur sagen wollt und es einfach erklären, man muss dran denken das mitunter die gepufferten Daten anwachsen können (sei denn man kann es verhindern, was dann auch eine Lösung des Problems währe). Blöd ist nur wenn man in einem Ringpuffer noch nicht wiedergegebene Daten überschreibt.

Zitat von p80286:

In diesem konkreten Fall ist da eher die Datenlieferung über das Netz der primär einschränkende Faktor.

Mir scheint so als ob diese Zeiten vorbei sind (Jedenfalls bei dem was ich über Web höre). Aussetzer habe ich in letzter Zeit immer seltener. Vor ein paar Jahren gab es schon öfters Tage wo Winamp nur am Neupuffern war.

einbeliebigername.

[Codehunter]

Zitat von einbeliebigername:

Mir scheint so als ob diese Zeiten vorbei sind (Jedenfalls bei dem was ich über Web höre). Aussetzer habe ich in letzter Zeit immer seltener. Vor ein paar Jahren gab es schon öfters Tage wo Winamp nur am Neupuffern war.

Das Netz ist ja nun mal nicht homogen. Niemand hindert einen Nutzer daran, einen kambodschanischen Webradioservice zu hören. Wenn es dabei zu Lags kommt könnte es durchaus daran liegen, dass in Kambodscha die Datenpakete noch in Eimern von A nach B getragen werden

Bei MP3- und MP4-Datenströmen liegt es ja in der Natur der Sache, dass die Bitrate nicht konstant ist sondern mit der Granularität des (analogen) Nutzsignals schwankt. Wenn ein Stream mit 320 kBit/s angegeben ist, dann ist das der Maximalwert und kann deutlich unterschritten werden. Entsprechend würde BASS dann aber auch wieder "langsamer ausgeben". Die Sache mit dem Quartz kann man ja auch im übertragenen Sinne so verstehen, dass BASS u.U. leichte Abweichungen in der Wiedergabegeschwindigkeit hat. Für den Nutzer zwar nicht hörbar aber irgendwann stieße das Ganze dann an die Grenzen des Puffers.

Es käme wohl letztlich auf den Versuch an, einen Webradiostream mal unkoordiniert über einen Ringpuffer laufen und von BASS wiedergeben zu lassen. Ich müsste mich mal in BASS einlesen ob man da eine Rückinfo bekommt wie viele Daten aus dem Puffer abgerufen und verarbeitet werden. Daraus ließe sich ja ermitteln, wie viele Daten am "unteren Ende" des Puffers verworfen werden können. Entsprechend hätte der Ringspeicher eine dynamische Größe und könnte anwachsen. Ein dynamischer Vorlauf von 3 Minuten oder gar einer Stunde wäre ja heutzutage kein großes Problem mehr, RAM ist ja i.d.R. genug da.

[einbeliebigername]

Hallo,

Zitat von Codehunter:

Das Netz ist ja nun mal nicht homogen. Niemand hindert einen Nutzer daran, einen kambodschanischen Webradioservice zu hören. Wenn es dabei zu Lags kommt könnte es durchaus daran liegen, dass in Kambodscha die Datenpakete noch in Eimern von A nach B getragen werden

Da hast du recht.

Zitat von Codehunter:

Es käme wohl letztlich auf den Versuch an, einen Webradiostream mal unkoordiniert über einen Ringpuffer laufen und von BASS wiedergeben zu lassen. Ich müsste mich mal in BASS einlesen ob man da eine Rückinfo bekommt wie viele Daten aus dem Puffer abgerufen und verarbeitet werden. Daraus ließe sich ja ermitteln, wie viele Daten am "unteren Ende" des Puffers verworfen werden können. Entsprechend hätte der Ringspeicher eine dynamische Größe und könnte anwachsen. Ein dynamischer Vorlauf von 3 Minuten oder gar einer Stunde wäre ja heutzutage kein großes Problem mehr, RAM ist ja i.d.R. genug da.

Vielleicht brauchst du die Info gar nicht bzw. hast sie schon. Ich bin leider in mehreren Jahren noch nicht dazugekommen mir die Bass.dll anzuschauen. Aber wenn die Bass einen TStream, iStream oder ähnliches wiedergeben kann, bekommst du doch automatisch im Streamobjekt mit wie viel wiedergegeben wurde.

Beim genaueren überlegen mein Vorschlag. Erstelle drei Klassen. Eine eigene Stream-Implementierung für den Schreiber (Webkomponente), eine eigene Stream-Implementierung für den Leser (Bass) und eine Ringpuffer-Implementierung. Die Stream-Klassen schreiben/lesen in/aus dem Ringpuffer.

Beim Ringpuffer entweder mit Datenblöcken (ein, zwei KB), welche über Zeiger verkettet sind, arbeiten. Hat den Vorteil das man Daten beim vergrößern des Puffer nicht umkopieren muss, sonder einen neuen Datenblock einfügen kann.

Oder man sieht im Ringpuffer ausreichend Platz für einige Minuten (vielleicht reichen auch Sekunden) vor. Und sollte es mal unter unvorstellbaren Gründen dazu kommen, dass dem Puffer der Platz ausgeht, wirft man bei Schreiben Daten weg. Dann springt die Wiedergabe etwas nach vorne und gleicht das wieder aus.

Ich würde die zweite Variante empfehlen. So würde bei einem wirklichen Livestream die Daten bei nicht zu großen Puffer nahe am Live wiedergegeben. Und bei den anderen kann man bestimmt steuern wie schnell die Daten aus dem Internet kommen.

einbeliebigername.