webradio aufnehmen

[Szin]

Hallo!
Ich möchte den Webradio-Stream eines Shoutcast Radios aufzeichnen. In den PLS-Datei sind die direkten Links in folgender Form:

http://64.236.34.4:80/stream/1032

Nun Frage ich mich als interessiertem Noob wie connecte ich den Server? Kann ich das über HTTP-GET machen? Oder verwendet man Sockets? Ist ja nicht nur ne ip mit nem port - das /stream/1032 stört irgendwie...

Und welche Komponenten verwendet man da heutzutage (habe gesehen das es verschiedene Sockets-Komponenten - gibt TStreamSocket, TTcpClient...)
Ach ja, das ganze sollte auch in einer nicht Dialog/fensterbasierten Umgebung funktionieren.

Grüße,
André

[Daniel G]

Zitat:

Zitat von Szin

Ist ja nicht nur ne ip mit nem port - das /stream/1032 stört irgendwie...

Das /stream/1032 gehört aber dazu. :stupid:

Port 80 ist ja der normale HTTP - Port. Im Prinzip müsstest du die Datei in den Cache laden und parallel abspielen (und danach das schon gehörte wieder aus dem Cache löschen).

[Tubos]

Du könntest einfach das populäre Programm streamripper aufrufen.

[Szin]

Das abspielen ist was für später (will ne Timeshift-Funktionalität haben)
Aber WIE mach ich nun das rauslesen?
Btw. gibts für HTTP auch ne nicht Indy-Komponente?

Ein externes Programm will ich nicht verwenden. Wär ja zu einfach ;-)

[Szin]

ok, hab nun TidHTTP und get verwendet (http://www.dsdt.info/tipps/?id=161)
Damit lässt sich der Stream in eine endlose Datei schreiben.
2 Probleme dabei:
1. Wie mach ich daraus einen ringpuffer? Sprich: Wie sagt ich dem Get das es nur zb. 1MB runterläd und dann wieder vorne anfängt?
Schwerwiegender ist 2.
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!
Dazu Ideen?
Grüße,
André

[Daniel G]

Zitat:

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?

[Szin]

2. hab ich jetzt wie folgt gelöst:

Delphi-Quellcode:

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

da

Delphi-Quellcode:

  fmCreate = $FFFF;

bringt eine or Verknüpfung natürlich nicht wirklich was ;-)
Nun muss ich "nur noch" 1. lösen - mal schaun!

André

P.S. BASS ost ne feine sache, kostet aber für kommerzielle Anwendungen Geld :(

[benst]

Ich weiß nicht, ob du das Programm umbedingt selber schreiben möchtest und wie weit du schon gekommen bist. Ich würde folgendermaßen machen:
Mit dem kostenlosen Programm Screamer das Radio-Programm anhören. Dann auf Aufnahme drücken und weggehen. Wenn du wiederkommst, einfach die gespeicherte mp3 mit z.B. Winamp starten (während weiter aufgenommen wird). Funktioniert bei mir zumindest super.
Ben
P.S.: Das Programm bietet zusätzlich auch noch die Funktion, dass schon vor dem Klicken auf Rec aufgenommen wird. Siehe auch D.-P.: Sound 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:

Zitat von Daniel G (Beitrag 516081)

Zitat:

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:

Zitat von Codehunter (Beitrag 1351113)

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:

Zitat von einbeliebigername (Beitrag 1351125)

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:

Zitat von Codehunter (Beitrag 1351165)

Zitat:

Zitat von einbeliebigername (Beitrag 1351125)

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:

Zitat von Sherlock (Beitrag 1351169)

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:

Zitat von Sherlock (Beitrag 1351169)

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:

Zitat von einbeliebigername (Beitrag 1351175)

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:

Zitat von p80286 (Beitrag 1351182)

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:

Zitat von p80286 (Beitrag 1351182)

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:

Zitat von einbeliebigername (Beitrag 1351188)

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 :-D

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:

Zitat von Codehunter (Beitrag 1351191)

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 :-D

Da hast du recht.

Zitat:

Zitat von Codehunter (Beitrag 1351191)

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.