webradio aufnehmen

[Codehunter]

Hallo!

Ich begehe hier jetzt mal den verwerflichen Akt der Leichenfledderei und hole diesen betagten Thread wieder hoch, weil mein Problem genau hier schon mal angerissen aber nicht abschließend beantwortet ist:

Zitat von Daniel G:

Zitat von Szin:

2. Die Datei lässt sich während des schreibens weder mit Winamp noch mit dem Windows Media Player öffnen, obwohl ich

Code:

  lStream:=TFileStream.Create('C:\Test.mp3', fmCreate or fmShareDenyNone);

verwende. Aber das ist Vorraussetzung für mich!

Und wenn du die Datei stattdessen in einen Puffer lädst und sie mit der BASS.DLL abspielst, sprich, einen eigenen Player integrierst?

Konkret geht es mir darum, einen Webradio-Stream per Indy-Get zu holen und dann direkt, ohne Dateipuffer, an BASS.DLL weiter zu reichen. Da BASS eine Stream-Schnittstelle hat und ich schon ein Tutorial dazu gefunden habe, sehe ich da im Moment weniger das Problem.

Vielmehr würde mich interessieren, wie man mit Indy quasi einen Endlos-Stream realisiert. Man braucht ja einen gewissen Vorlauf an Nutzdaten im Stream und müsste die von BASS bereits wiedergegebenen Daten verwerfen, damit einem nicht irgendwann ein Puffer voll läuft. Das Problem ist also, genug Nutzdaten im Puffer vorzuhalten, die Wiedergabe zu synchronisieren und "veraltete" Daten zu verwerfen ohne den Stream zu schließen.

Da wär ich mal für dein ein oder anderen Tip dankbar.

Grüße
Cody

[einbeliebigername]

Hallo,

Zitat von Codehunter:

Vielmehr würde mich interessieren, wie man mit Indy quasi einen Endlos-Stream realisiert. Man braucht ja einen gewissen Vorlauf an Nutzdaten im Stream und müsste die von BASS bereits wiedergegebenen Daten verwerfen, damit einem nicht irgendwann ein Puffer voll läuft. Das Problem ist also, genug Nutzdaten im Puffer vorzuhalten, die Wiedergabe zu synchronisieren und "veraltete" Daten zu verwerfen ohne den Stream zu schließen.

Da wär ich mal für dein ein oder anderen Tip dankbar.

Grüße
Cody

Das Stichwort währe Ringpuffer. Himitsu hat da mal einen Streambasierten gepostet (http://www.delphipraxis.net/126525-t...-memory.html#7). Du musst nur das Problem lösen, dass vermutlich die Abspielgeschwindigkeit nur annähernd gleich der Datenanlieferung ist.

einbeliebigername.

[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