Kommt drauf an was für ein "Containerformat" das Zeug hat.

Ein Webradio ist nicht gleich Webradio. Das ist wie jedes andere Dateiformat aufgebaut nur, dass nicht streaming fähige Dateiformate ausgeschlossen werden. z.B. wird MP3 unterstützt, da MP3 die Daten in Frames gliedert, denen einen Header verpasst wo Samplerate etc. drinnen steht. Das gleiche gilt für AAC, OGG(als Containerformat gesehen => somit eher OGG-Vorbis),...
Bleiben wir bei MP3. Dort kommen Album, Titel,... von sogenannten ID3-Tags. Laut Spezifikation befindet ID3v2 am Anfang gekennzeichnet durch "ID3" und ID3v1 sind die letzen 128 Bytes.
Legen wir das auf ein Radio um ... hmmm so stellen wir bald fest, dass dadurch Probleme entstehen. Welche? Es gibt keinen Anfang und kein Ende!
Also wurde Ersatz geschaffen. In unregelmäßigen oder regelmäßigen Abständen wird neben z.B. MP3-Frames eine gewisse Datenmenge gesendet welche eben nicht als MP3-Frame interpretiert werden kann. Und hier gibt es eben verschiedene Formate. Zum Beispiel IceCast, Shoutcast,... welche eben solche "Info-Frames" mit den Audio-Daten vermischen und du somit regelmäßig lesen kannst.

Dann müsstest Du Dich auf den

Marceliboy schrieb:

webradio-homepages

informieren, wie deren entsprechende Informationen codiert sind.

Nö ist es nicht, da solche "Info-Frames" auch wieder einer Spezifikation unterliegen und identifiziert werden können. Entsprechend um was es sich handelt, muss dann halt decodiert werden.
Eventuell unterstützt dies deine Bibliothek schon, wenn nicht kannst du umsteigen oder du suchst dir eine Bibliothek speziell für das ODER du holst dir über die HttpWebResponse den ResponeStream und parst diesen selben. Methode 2 und 3 sind natürlich erheblicher Datenoverhead.