Webcasting: Möglichkeiten der Automatisierung

Transcription

Fachhochschule Furtwangen
Fachbereich Digitale Medien
Studiengang Medieninformatik
WEBCASTING:
MÖGLICHKEITEN
DER
AUTOMATISIERUNG
Diplomarbeit Sommersemester 2001
Martin Zinßer
mz@mzed.de
Betreuende Professoren:
Erstbetreuer: Prof. M.A. A. Schäfer-Schönthal
Zweitbetreuer: Prof. Dr. U. Dittler
Eidesstattliche Erklärung:
Ich erkläre hiermit an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und
ohne unzulässige fremde Hilfe angefertigt haben. Alle verwendeten Quellen und
Hilfsmittel sind angegeben.
Furtwangen, den 31. August 2001
Inhaltsverzeichnis
Inhaltsverzeichnis
Eidesstattliche Erklärung:
III
Abbildungsverzeichnis
IX
Abkürzungsverzeichnis
XI
Zusammenfassung
1
2
Einleitung, Problemstellung, Zielsetzung
XIII
1
1.1 Einleitung
1
1.2 Was bedeutet Webcasting?
1
1.2.1 Formen von Webcasting
1
1.2.2 Streaming
3
1.2.3 Live Webcasting
4
1.2.4 On-demand
4
1.2.5 Push-Dienste
5
1.2.6 Automatisierte Pull-Dienste
5
1.3 Webcasting im Sinne dieser Arbeit
6
1.4 Ein Problem - Das optimale Webcsting System
7
1.5 Das Ziel – Was soll am Ende herauskommen?
9
Systeme, Voraussetzungen und Konzepte
11
2.1 Marktübersicht und Stand der Technik
11
2.1.1 Streaming Systeme
11
2.1.2 Professionelle Automationssysteme für Webcasting
14
2.1.3 Sonstige Tools
16
2.2 Voraussetzungen für Automation
17
2.2.1 Technische Voraussetzungen
17
2.2.2 Inhaltliche Aspekte
18
2.2.3 Voraussetzungen an den Internetauftritt
19
2.2.4 Produktionsrichtlinien
19
2.3 Konzepte im Bereich Webcasting
20
V
Diplomarbeit von Martin Zinßer
3
2.3.1 Einführung
20
2.3.2 Bestehende Konzepte
21
2.3.2.1
Datensammlung
21
2.3.2.2
Ergebnisse
23
2.3.3 Innovative Konzepte
26
2.3.3.1
Services/Information
26
2.3.3.2
Interaktion
27
2.3.3.3
Anwendungsbereiche
28
2.3.4 Ergebnisse
29
Praktische Umsetzung
31
3.1 Ausgangsbedingungen der Umsetzung
31
3.2 Die einzelnen Stufen der Realisierung
32
3.2.1 Realisierungsstufe 1
3.2.1.1
Radio GLF on Air 24/7
32
3.2.1.2
Technische Umsetzung Realisierungsstufe 1
33
3.2.1.3
Der praktisch Einsatz von Realisierungsstufe 1 39
3.2.1.4
Probleme
40
41
3.2.2.1
„Jetzt läuft“ und „Die letzten 10“
41
3.2.2.2
45
3.2.2.3
Praktischer Einsatz Realisierungsstufe 2
54
3.2.2.4
Probleme
57
61
3.2.3.1
Wünsch’ dir’s mit SAM
61
3.2.3.2
65
3.2.3.3
75
3.2.3.4
Probleme
77
VI
32
79
3.2.4.1
Push it & GLF2
79
3.2.4.2
80
Inhaltsverzeichnis
4
5
6
3.2.4.3
83
3.2.4.4
Probleme
84
Dokumentation und Analyse des Hörerverhaltens
85
4.1 Methodik
85
4.2 Dokumentation
86
4.3 Analyse
88
Fazit und Ausblick
89
5.1 Fazit
89
5.2 Ausblick
89
Literaturverzeichnis
91
A Produktionsrichtlinien
95
B Inhalt der CD
99
VII
VIII
Abbildung: 1-1:
Formen von Webcasts
3
Abbildung: 2-1:
Tabelle Radio Station Web Site Features
22
Abbildung: 2-2:
Tabelle Features deutsche Radiosender Websites
22
Abbildung: 2-3:
SWR3 Player
23
Abbildung: 2-4:
Big FM SMS Track-Check
24
Abbildung: 2-5:
DASDING Playliste
25
Abbildung: 3-1:
Vorhandene Bandbreiten Radio GLF Zielgruppe
34
Abbildung: 3-2:
Schema Realisierungsstufe 1
36
Abbildung: 3-3:
Radio GLF Webseite, Anfang SS 2001
43
Abbildung: 3-4:
Signalfluss duch Winamp Plug-ins
45
Abbildung: 3-5:
Winamp ID3 Tag Editor
46
Abbildung: 3-6:
Schema Realisierungsstufe 2
48
Abbildung: 3-7:
Realisierungsstufe 2 - Schema DoSomething
51
Abbildung: 3-8:
Realisierungsstufe 2 in Betrieb
54
Abbildung: 3-9:
Hörerzufriedenheit
63
Abbildung: 3-10:
Realisierungsstufe 4 - SAM Setup
69
Abbildung: 3-11:
ASQ Skript
73
Abbildung: 3-12:
Tabelle Netzwerklaufwerke
75
Abbildung: 3-13:
SAM Remote Admin
77
Abbildung: 3-14:
Logo GLF2
80
Abbildung: 3-15:
Realisierungsstufe 4 - ChangeDetect
83
Abbildung: 4-1:
Absolute Anzahl an Shoutcast-Verbindungen pro Tag
86
Abbildung: 4-2:
Absolute Anzahl an Shoutcast-Verbindungen pro Stunde
86
Abbildung: 4-3:
Radio GLF Webserver Statistiken
87
IX
X
AAT
Advanced Audio Tags
AIM
AOL Instant Messenger
AOL
America Online
ASF
Active Streaming Format
ASP
Active Server Pages
ASQ
Auto Song Queing
DAB
Digital Audio Broadcasting
DHTML
Dynamic HTML
DSP
Digital Signal Processing
DV
Digital Video
GLF
Gute Laune Furtwangen
HTML
Hypertext Markup Language
ICQ
I seek You Instant Messenger
IIS
Internet Information Server
IM
Instant Messenger
IP
Internet Protocol
ISDN
Integrated Services Digital Network
ISP
Internet Service Provider
kbps
kilobits per second
LAN
Local Area Network
Mbps
Megabits per second
MPEG
Motion Pictures Expert Group
MH
Musikhochschule
MMS
Microsoft Media Server Protocol
MS
Microsoft
PAD
Program Associated Data
PHP
Hypertext Preprocessor
RTP
Real-Time Transport Protocol
RTSP
Real-Time Streaming Protocol
SAM
Streaming Audio Manager
XI
SMS
Short Message Service
SWR
Südwestrundfunk
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
UMTS
Universal Mobile Telecommunications Service
URL
Uniform Resource Locator
WAP
Wireless Application Protcol
WDR
Westdeutscher Rundfunk
WPV
Wahlpflichtfach
WWW
World Wide Web
XII
Zusammenfassung
Zusammenfassung
Diplomarbeit "Webcasting: Möglichkeiten der Automatisierung" von Martin
Zinßer, FH Furtwangen, Sommersemester 2001.
Der Begriff Webcasting ist ein Kunstwort, das sich aus den Begriffen World Wide Web
und Broadcasting zusammensetzt. Webcasting beinhaltet das Streaming Audio- und
Videoinformationen
in
Live-Situationen
und
on-demand,
sowie
Push-
oder
automatisierte Pull-Dienste.
Eine offizielle Definition des Begriffs existiert nicht, deshalb gibt es mehrere
Möglichkeiten der Auslegung. In dieser Arbeit bedeutet Webcasting das internetbasierte
Streaming von Audioinhalten und begleitenden Zusatzinformationen wie Bildern,
Grafiken und Texten sowie die Bereitstellung von Interaktionsmöglichkeiten für die
Benutzer.
An ein Automationssystem für Webcasting werden neue Anforderungen gestellt, die
konventionelle Radioautomationssysteme nicht erfüllen können. Die Anforderungen
lassen sich auf die drei Funktionsbereiche Streaming, dynamische WebseitenGenerierung und Interaktivität reduzieren. Ein optimales Webcasting-System muss
Schnittstellen implementieren, die es ermöglichen, den passiven Zuhörer zum aktiven
Nutzer zu wandeln.
Die vorliegende Arbeit geht von theoretischen Untersuchungen und Konzepten aus, die
im praktischen Teil der Arbeit im Rahmen des Internet Hochschul Senders "Radio GLF"
umgesetzt werden. Ziel ist ein einsatzfähiges System, das den Anforderungen von
Webcasting genügt.
Für die Automatisierung von Webcasting und die Nutzung von müssen von Anbieterseite
Voraussetzungen in den Bereichen Technik, Inhalt und Internet erfüllt werden um
erfolgreiches Webcasting mit viel Interaktion und Information zu realisieren.
Der praktische Teil der Arbeit dokumentiert vier Realisierungsstufen. In jeder Stufe wird
das automatisierte Webcasting - Angebot von Radio GLF erweitert. Das Spektrum reicht
vom einfachen Streaming bis zum interaktiven Infotainment Angebot auf zwei Kanälen.
Die steigende Popularität von Radio GLF kann mit Logfiles der Server belegt werden.
XIII
XIV
Einleitung - Formen von Webcasting
1
Einleitung, Problemstellung, Zielsetzung
1.1 Einleitung
Webcasting ist die faszinierende Möglichkeit, mit wenig Mitteln einen eigenen
Sender im Internet zu betreiben.
Webcasting ist das Schlagwort zum Thema "Konvergenz von Rundfunk, TV und
Internet".
Webcasting ist die Hoffnung der Industrie auf neue Vertriebswege und neue
Marketingformen.
Webcasting ist die Bezeichnung eines Wahlpflichtfaches an der FH
Furtwangen, aus dem der Internet Radiosender "Radio GLF" entstanden ist.
Radio GLF sendet zu Beginn des Sommersemesters 2001 nur eine Live-Sendung pro
Woche, in der restlichen Zeit herrscht digitale Funkstille. Diese Stille war der Anlass
dafür, mich mit den Möglichkeiten der Automatisierung bei Webcasting auseinander
zusetzen um schließlich das Programm von Radio GLF rund um die Uhr empfangbar zu
machen und mit innovativen Funktionen aufzuwerten.
In theoretischen Teil dieser Arbeit werden die verschiedenen Werkzeuge, Grundlagen
und Systeme vorgestellt, die für Webcasting nötig sind. Vorhandene Konzepte werden
vorgestellt und bewertet. Basierend auf der Recherche nach Konzepten im Bereich
Webcasting ist eine funktionsfähige Umsetzung dieser Konzepte der gewichtigste Teil
dieser Arbeit. Die Umsetzung der Konzepte erfolgt im Rahmen des Hochschulradios
"Radio GLF" und ist in vier Realisierungsstufen unterteilt. Zu jeder Stufe gibt es eine
sehr ausführliche Dokumentation zu Idee, Ausführung und praktischer Einsatz der
jeweiligen Stufe.
1.2 Was bedeutet Webcasting?
1.2.1 Formen von Webcasting
Webcasting ist ein Kunstwort, das sich aus den Begriffen World Wide Web und
Broadcasting zusammensetzt. Genaugenommen heißt es also nichts anderes als
verteilerorientiert Sendungen in das WWW vorzunehmen. Daraus ergeben sich mehrere
Möglichkeiten, was denn unter Webcasting verstanden werden kann und auch wird.
1
Ein sehr wichtiger Aspekt dabei ist der der „Sendung“. Senden bedeutet, dass die Inhalte,
die transportiert werden, ohne weiteres Engagement des Empfängers empfangen werden.
Ist der Empfang erst einmal eingerichtet und gestartet, erreichen die Inhalte ihr Ziel
eigenständig und ohne weitere besondere Aufforderung.1
Verteilerorientiert heißt, dass es sich nicht um 1:1 Kommunikation handelt, sondern um
1:n Kommunikation. Die Inhalte werden also von vielen gleichzeitig empfangen.
Bis hierhin trifft die Definition auch noch auf die klassischen Broadcast-Medien wie
Rundfunk und Fernsehen zu. Der „Web“ -Anteil drückt sich dadurch aus, dass das
Internet als Verteilmedium für die Informationen genutzt wird.
Ein weiteres Merkmal von Webcasting ist, dass meist ein gewisser Grad an Interaktivität
angeboten wird, der eine aktive Beteiligung des Nutzers am jeweiligen Webcasting Angebot fordert. Darin besteht ein klarer Unterschied zu den passiven Medien Rundfunk
und Fernsehen, die man zu den „lean-back“ Medien zählen kann, wohingegen
Webcasting ein aktives, „lean-forward“ -Medium ist.2
Es gibt keine offizielle Definition von Webcasting, so dass viele Leute verschiedene
Dinge darunter verstehen.3
In der nachfolgenden Abbildung 1-1werden verschiedene Formen von Webcasts kurz
erläutert. Die verschiedenen Formen sind von oben nach unten mit einem steigenden
Grad an Interaktivität anordnet. Außerdem nimmt die Zahl der einbezogenen Medien zu.
Während bei „Automatisiertes Pull“ und „Push-Dienste“ nur üblicherweise Standbilder
und Textinhalte verarbeitet werden und keine Interaktivität möglich ist, können bei
„Event-Webcasting“ alle weiter oben genannten Formen eingebunden sein. So kann z.B.
bei einer Aktionärsversammlung die Versammlung live gestreamt werden, die
verwendeten Folien bei einer Präsentation gepusht werden und im Archiv kann der
Mitschnitt der vorangegangenen Versammlung on-demand zur Verfügung stehen.
1. Ein Gegenbeispiel ist der Faxabruf, bei dem der Empfänger erst selbst einige Schritte unternehmen
muss um an die gewünschten Informationen zu kommen.
2. Vgl. Hillebrand, 2000, Entwicklungsperspektiven, S. 3
3. Siehe auch: Miles, 1998, Guide, S.1: “Webcasting can be any or all of the following:
1. Broadcasting
2. Videoconferencing
3. One-to-one communications, like an Internet phone conversation”
2
Was bedeutet Webcasting? - Streaming
Name
Beschreibung
Beispiel
Automatisiertes Pull
Automatische Aktualisierung von (durch
Nutzer definierten) Webseiten
Browser-Channels
Push-Dienste
Abonnierte, jeweils aktuell übermittelte
Informationsservices
News- und Börsenticker
„Rundfunk / Fernsehen
über Web“
Streaming vorhandener Rundfunk/TVProgramme über das Internet
On-demand Webcasting
Bereitstellen von Audio- und
Videoinformationen mit weiteren
Services über das Internet auf einer
Website
Websites von Rundfunk-,
TV-Sendern oder
Printmedien
Event-Webcasting
Nutzung des Internets zur Übertragung
exklusiver Audio- und Videoinhalte
(häufig auch live)
Aktionärsversammlungen,
Tagungen,
Pressekonferenzen, SpecialEvents (Konzerte,
Sportereignisse, ...)
Hörfunkprogramme,
Nachrichten, TVSendungen
Quelle: in Anlehnung an Hillebrand, 2000, Entwicklungsperspektiven, S. 26
Abbildung: 1-1 Formen von Webcasts
Nachfolgend wird eine genauere Definition von Webcasting herausgearbeitet, um
schließlich zu einer Definition zu kommen, die für diese Arbeit Gültigkeit hat. Dabei
wird nochmals auf die einzelnen Formen von Webcasts eingegangen.
1.2.2 Streaming
Mit dem Internet als Medium können nicht nur Texte und Grafiken, wie bei einfachen
HTML-Dokumenten übertragen werden, sondern es besteht insbesondere die
Möglichkeit Audio- und Videodaten zu übertragen. Geschieht das Empfangen von z.B.
Sprache, Musik und Kamerabildern in Echtzeit, so wird dieser Vorgang als Streaming
bezeichnet. Diese relativ neue Technologie ermöglicht es, einen Bit-„Strom“ mit Videound/oder Audiodaten zu empfangen und darzustellen, ohne dass vorher ein komplettes
Herunterladen der Datei nötig ist. Ein „... Streaming-System [besteht] wie ein
‚herkömmliches’ Radio aus den Komponenten Sender, Übertragungsweg und
Empfänger. Der Sender ist ein PC mit einem Kodierungsprogramm (und
nachgeschaltetem Server). Die Übertragungsstrecke entspricht dem Internet. ... Als
Empfänger dient z.B. ein über ein Modem an das Internet angeschlossener PC (Client)
mit einem Dekodierungsprogramm.“1
3
Streaming ermöglicht also ein radio- oder fernsehartiges Erlebnis mit dem Rechner als
Empfangsgerät. Das empfangene Material kann dabei „live“, oder „on-demand“ sein.
1.2.3 Live Webcasting
Live Webcasting entspricht der live Übertragung bei Rundfunk und Fernsehen. Ein
bestimmtes Ereignis, wie z.B. eine Konferenz, ein Fußballspiel oder Konzert wird in
Echtzeit ins Internet übertragen. Um einen korrekten Empfang der Audio- oder
Videoübertragung zu ermöglichen, wird das Ereignis vom Rechner in einen
kontinuierlichen Bitstrom gewandelt. Die Sendung kann dann mit etwas Verzögerung
beim Empfänger wiedergegeben werden. Die Verzögerung entsteht dabei durch die
paketorientierte Übertragung der Daten im Internet und der damit nötigen
Zwischenspeicherung der Daten in Puffern.
Da mit dem Internet als Übertragungsmedium auch ein Rückkanal vom Empfänger zum
Sender vorhanden ist, ist es von technischer Seite aus kein Problem den Empfänger in
die Sendung mit einzubeziehen. Ein höheres Maß an Interaktivität im Vergleich zu
konventionellen Übertragungen ist möglich. „Webcasting permits users to interact with
the event as it is happening, for example, … clicking on the video of a NASA launch to
visit the control tower and hear the controllers’ instructions to the astronauts while
reviewing the specification details for equipment and fuel.”1
1.2.4 On-demand
Bei „on-demand“– Diensten befindet sich die Sendung auf dem Server des
Dienstanbieters und kann über einen entsprechenden Link vom Benutzer aufgerufen und
in Echtzeit konsumiert werden. Dabei spielt der Zeitpunkt des Aufrufs keine Rolle,
ähnlich wie man bei einem Videorekorder eine aufgenommene Kassette willkürlich
abspielen kann. Analog zum Videorekorder stehen bei „on-demand“ –Übertragungen
„Pause“, „Stop“, „Vor“ und „Zurück“ -Funktionen zur Verfügung. Da es sich um eine
Übertragung von Archiv-Inhalten handelt ist die Interaktivität im Vergleich zu einer
Live-Sendung eingeschränkt. Der Nutzer kann keinen Einfluss auf das (vergangene)
1. Wegner/Bachmeier, 2000, Streaming Media, S. 15
1. Miles, 1998, Guide, S. 30f
4
Was bedeutet Webcasting? - Push-Dienste
Ereignis ausüben, jedoch kann er z.B. zwischen verschiedenen Kamerapositionen
wechseln oder sich durch verlinkte (Bild-)Inhalte Zusatzinformationen beschaffen.
1.2.5 Push-Dienste
Webcasting beinhaltet aber auch den gesamten Bereich der Push-Dienste.1 Dabei werden
Daten, wie z.B. Texte oder Bilder automatisch vom Server des Dienstanbieters2 zum
Rechner des Nutzers übertragen. Nicht-computerisiert existieren Push-Dienste schon
länger z.B. in Form von Magazin- und Zeitschriftenabonnements. Die Verteilung von
selektierten Informationen an einen bestimmten Benutzerkreis bringt Vorteile für Sender
wie auch Empfänger. Der Sender kann den Inhalt der gepushten Informationen genau
abstimmen, eine hohe Effizienz der Botschaft ist die Folge. Der Empfänger auf der
anderen Seite hingegen spart Zeit und Aufwand um entsprechende Informationen zu
bekommen, denn die zeitraubende Benutzung von Suchmaschinen entfällt. Oft ist für
den Empfang von Push-Informationen spezielle Software nötig, vergleichbar mit Instant
Messenger - Applikationen. Genaugenommen gehören auch Emails (z.B. in Verbindung
mit Mailing-Listen) zu den Push-Diensten. Ursprünglich war diese Form der
Informationsübermittlung auch für Werbeinhalte vorgesehen, die Unbeliebtheit von
Werbe-Mails verhinderte dies schließlich. Internet-Provider wie AOL oder Juno3 pushen
jedoch auch heute noch Werbung an ihre Kunden über die proprietäre Zugangssoftware.
Da mit den Push-Diensten eine effiziente und zeitkritische Übermittlung von Daten
möglich ist, wird sie hauptsächlich für Informationen aus den Bereichen Börse,
Wirtschaft und Politik verwendet.
1.2.6 Automatisierte Pull-Dienste
Eine Variante der Push-Dienste sind Verfahren mit automatisierten Pull-Techniken. Hier
wird die Anforderung des Dokuments automatisch vom Rechner des Nutzers
durchgeführt. Microsoft und Netscape haben diese Technik in ihre Browser eingebaut
(„Channel“ bzw. „My Sidebar“). Der Nutzer kann dabei nach seinen Wünschen Seiten
1. In manchen Fällen beschränkt sich die Definition auch nur auf diese Dienste, vgl. Eichstädt, 2000,
Profiles, S. 8ff
2. wie z.B. von Pointcast - http://www.pointcast.com/, BackWeb - http://www.backweb.com/ oder
Marimba – http://www.marimba.com/ . Weitere Adressen sind zu finden in Miles, 1998, Guide, S. 344ff
3. http://www.aol.com/ bzw. http://www.juno.com/
5
festlegen, die dann im Hintergrund lokal auf seine Festplatte gespeichert werden und so
offline zur Verfügung stehen. Aufgrund mangelnder Akzeptanz von Nutzerseite werden
diese Funktionen jedoch nicht mehr automatisch installiert.
Technisch gesehen gehören auch Reloads von HTML-Seiten zu den Automatisierten
Pull-Diensten. Diese Technik wird z.B. für Werbe-Banner, aktuelle Informationen und
Nachrichten verwendet. Sekundengenaue Synchronität von Daten mit Ereignissen ist
hiermit jedoch nicht realisierbar.
1.3 Webcasting im Sinne dieser Arbeit
„Insgesamt kann Webcasting als eine Technologie definiert werden, die auf
den Protokollen des Internet aufsetzt und das WWW als Benutzeroberfläche
verwendet. Im Gegensatz zu dem in erster Linie ’pull’ -orientierten Charakter
der Internets ist jedoch Webcasting vor allem dadurch gekennzeichnet, dass es
auch passiv empfangbar ist und über einen hohen Anteil an Audio-, Bild- und
Videoinformationen verfügt.“1
Die Definition von Webcasting im Sinne dieser Arbeit wird jedoch eingeengt. Denn
wesentlich mehr Nutzer konsumieren Audioangebote wenn sie online sind als
Videoangebote - in den USA sind es beispielsweise 36% (Audio) zu 20% (Video) der
Internetnutzer.2 Deshalb scheint eine Automatisierung von Streaming Audio
Anwendungen sinnvoller als von Streaming Video Anwendungen. Es sind bei der
praktischen Umsetzung weniger technische Probleme zu erwarten. In dieser Arbeit gilt
daher folgende Auslegung:
Webcasting ist internetbasiertes Streaming von Sprache, Musik und Standbildern, mit
programmbegleitenden Zusatzinformationen wie Bildern, Grafiken, Texten sowie die
Bereitstellung von Interaktionsmöglichkeiten für den Benutzer. „On-demand“ –Dienste
sowie reine Push-Dienste werden dabei nicht berücksichtigt,
Im weiteren Verlauf der Arbeit bezieht sich Webcasting also nur auf obige,
eingeschränkte Definition.
1. Hillebrand, 2000, Entwicklungsperspektiven, S. 5
2. Arbitron, 2001, The Need for Speed, S. 10
6
Ein Problem - Das optimale Webcsting System - Automatisierte Pull-Dienste
1.4 Ein Problem - Das optimale Webcsting System
Webcasting und Automatisierung. Was kann und sollte überhaupt bei Webcasting
automatisiert werden? Welche Möglichkeiten gibt es bereits, und welche weiteren
Möglichkeiten scheinen sinnvoll und wünschenswert? Welche Bedürfnisse und
Anforderungen haben die Hörer, bzw. Nutzer an Zusatzinformationen, die über das
Internet präsentiert werden können?
Da in der vorliegenden Arbeit nur auf Webradio, insbesondere auf den Studentensender
„Radio GLF“, Bezug genommen wird, liegt es Nahe, sich klassische RadioautomationsSysteme anzuschauen und auf ihre Verwendbarkeit im Bereich Webcasting zu
überprüfen. Allerdings ist schon ohne weitere Recherche denkbar, dass diese Systeme
komplex und teuer sind, da sie den Anforderungen von kommerziellen Radiostationen
genügen müssen. Radioautomations-Systeme unterstützen die Radiomacher bei ihrer
Arbeit. Diese müssen den passenden Mix an Musik, Unterhaltung und Informationen
finden und „programmieren“, der möglichst vielen gefällt und auch noch perfekt auf die
Zielgruppe abgestimmt ist. Schon ein oder zwei unpassende Musikstücke können dazu
führen, dass die Hörer zu einem anderen Sender umschalten. Professionelle
Automationssysteme müssen deshalb sehr ausgefeilte und genaue Werkzeuge bieten, um
Sendeabläufe zu planen und die Übersicht über das Gesamtprogramm zu erleichtern.
Man
bezeichnet
dieses
Modul
des
Gesamt-Automations-System
auch
als
Musikplanungs- oder Rotations-Software.1
Ist der Sendeablauf erstellt, werden die Daten üblicherweise an ein Ausspiel-System
weitergereicht. Diese spielte dann die einzelnen Titel, Beiträge und Werbeblöcke zur
vorprogrammierten Zeit ab oder wartet im sog. „live-assist“ Betrieb auf die
Synchronisierungs-Signale des Moderators oder Technikers, welche diese z.B. durch
Hochziehen eines Reglers generieren.2
Eine weitere wichtige Funktion, die ein solches System bieten muss, ermöglicht die
Abrechnung mit der GEMA und den Werbekunden. Das gesendete Programm kann
lückenlos dokumentiert und nachgewiesen werden. So kann genau nachvollzogen
1. Historisch waren diese Systeme schon in den 70ern auf dem Markt und können deshalb auch
alleinstehend benutzt werden. Ein nachfolgendes Ausspiel-Modul ist nicht nötig, die Titel und Beiträge
werden dann mit Hilfe einer Liste von Hand abgefahren.
2. Dies funktioniert z.B. bei Mischpulten mit „Fader-Start“ Einrichtung.
7
werden, wann wie oft bestimmte Werbeblöcke geschaltet wurden. Dabei muss auch die
eventuelle Aufteilung des Programms in Regionalfenster Beachtung finden. Es werden
also mehrere detaillierte Listen erstellt.
Der
in
den
obigen
Abschnitten
erläuterte
große
Funktionsumfang
der
Automationssysteme ist nicht direkt auf Webcasting abgestimmt. Einige Funktionen
werden nicht benötigt, andere wiederum fehlen. Durch entsprechende Plug-ins
versuchen die Hersteller dieses Manko auszugleichen, die Anschaffungskosten des
Systems werden aber dadurch weiter erhöht,
jedoch rechtfertigt die kommerzielle
Nutzung dies wiederum.
Die neuen Anforderungen, die durch Webcasting an ein Automationssystem gestellt
werden können, lassen sich auf folgende drei Funktionen reduzieren:
1. Streaming
Essentiell für ein Webcasting-System nach obiger Definition ist, dass ein
internetfähiger Audiostream des Ausgangsignals zur Verfügung gestellt wird.
Mehrere Bitraten, sowie die Unterstützung mehrerer Streamingformate für
verschiedene Anwendergruppen müssen möglich sein.
2. Dynamische Webseiten-Generierung
Mit dem Internet als Informationsmedium ist ein Audiostream, der über die
Webseite des Senders empfangen kann nicht ausreichend. Die Erstellung von
Webseiten, die sich dynamisch an die gesendeten Inhalte anpassen und
entsprechende Zusatzinformationen anzeigen müssen auch möglich sein.
3. Interaktivität
Konventionelle Interaktionsmöglichkeiten des Hörers mit dem Sender wie
Telefon, Fax, Brief und neuerdings Email sind bei einem Webcasting-System
nicht ausreichend und lassen sich vor allem schwer Automatisieren. Bei
Webcasting ist es notwendig, dass der Hörer bzw. Nutzer sein
Interaktionsbedürfnis auf der Webseite befriedigen kann. Möglichkeiten hierbei
sind: verschiedene Formen von Rückkanälen zum Sender,
Anpassungsmöglichkeiten / Personalisierung der Webseite, ein Angebot an
Zusatzdiensten und –informationen bis hin zur direkten Einflussnahme auf den
Sendeablauf.
8
Das Ziel – Was soll am Ende herauskommen? - Automatisierte Pull-Dienste
Zusammenfassend lässt sich das Problem folgend schildern: Es gibt eine Reihe an
Automationssystemen, die aus der herkömmlichen Radiowelt stammen. Der
Einsatzbereich ist aber aufgrund deren Funktionsumfang und Preis nicht unbedingt für
jeden Webcasting- Einsatz sinnvoll. Es wird deshalb eine System gesucht, welches den
neuen Anforderungen an ein spezielles Webcasting-System genügt und entsprechende
Möglichkeiten und Schnittstellen implementiert. Der bloße Hörer soll in einen
Zuschauer und Nutzer gewandelt werden.
1.5 Das Ziel – Was soll am Ende herauskommen?
Die theoretischen Untersuchungen und Konzepte sollen am Ende meiner Arbeit auch
eine praktische Umsetzung finden. Das Ziel ist eine Zusammenstellung an Tools, die es
ermöglichen, eine automatisierte Webcasting- Sendung mit programmbegleitenden
Zusatzinformationen zu erstellen. Insbesondere ist dabei die Erstellung von dynamischen
textlichen und visuellen Komponenten für die Webseite des Senders eine wichtige
Funktionseigenschaft.
Weiterhin soll das System so weit wie möglich plattformunabhängig sein. Die
Unabhängigkeit bezieht sich dabei sowohl auf die Hardware und Betriebssysteme von
Sender und Empfänger, als auch in bedeutenderem Maße auf die Möglichkeit
verschiedene Streaming-Systeme, Encoder und Server zu verwenden. Dadurch wird
garantiert, dass auch nach dem Wechsel zu einem anderen Streaming-System die
Funktionseigenschaften des automatisierten Webcasting-Systems erhalten bleiben.
Ein modularer Aufbau des Systems ist ein weiteres Kriterium, dass Beachtung finden
muss. Einzelne Komponenten des Systems müssen ausgetauscht werden können, so dass
eine Erweiterung des Funktionsumfangs oder Anpassung an Neuerungen im
Softwarebereich (wie z.B. neue Versionen von Tools) sowie der Produktionsumgebung
möglich sind. Realisiert werden kann dies beispielsweise durch ein Plug-in Struktur,
oder durch einzelne kleine Anwendungen, die miteinander über eine definierte
Schnittstelle kommunizieren.
Die Kosten des Systems spielen meist eine große Rolle. Idealerweise sollte das System
nichts kosten oder zumindest sehr günstig sein. Damit schränkt sich die verfügbare
9
Software auf den Shareware und Freeware Bereich ein, außerdem könnten von
studentischer Seite entsprechende Programme entwickelt werden.
Kommerzielle
Aspekte,
also
Möglichkeiten
mit
dem
System
z.B.
durch
Zweitverwertung Geld zu verdienen werden bewusst außer Acht gelassen. Die dabei
aufkommenden rechtlichen und organisatorischen Fragestellungen würden den Rahmen
dieser Arbeit sprengen.
Schließlich ergibt sich aus diesen Zielsetzungen ein System, dass für HochschulradioProjekte, kleine nicht-kommerzielle Radiostationen geeignet ist. Denkbar wäre auch der
Einsatz in den Intranets von Firmen als günstiges System um Corporate Radio /
Webcasting zu betreiben.
Eine weiter Zielsetzung ist es, Konzepte für innovative Ideen zu erstellen sowie deren
grundsätzliche Realisierungsmöglichkeiten aufzuzeigen. Aufgrund der begrenzt zur
Verfügung stehenden Zeit wird eine tatsächliche Umsetzung dieser Konzepte nicht
möglich sein.
10
Marktübersicht und Stand der Technik - Streaming Systeme
2
Systeme, Voraussetzungen und Konzepte
2.1 Marktübersicht und Stand der Technik
2.1.1 Streaming Systeme
Im folgenden Kapitel werden die verschiedenen Streaming-Systeme sowie Tools
führender Hersteller kurz vorgestellt. Ein ausführlicher Vergleich der Systeme ist im
Rahmen dieser Arbeit nicht möglich, da vor allem eine plattform- bzw.
systemunabhängige Lösung angestrebt wird.
RealNetworks (http://www.realnetworks.com/) :
RealSystem Server: Server für live und on-demand Inhalte im Real Format, verwendet
RTSP (Real Time Streaming Protocol), SureStream Technolgie erlaubt mehrere
Bitraten in einer Datei. Geeignet für die Übertragung von Audio, Video und
Multimedia (RealPix, RealText, RealFlash), Synchronisation mit SMIL. Verfügbar
für Windows NT, Linux, Unix: Beschränkte Basisversion kostenlos, unbeschränkte
Versionen ab $2000.
RealProducer: Encoder um live oder on-demand Audio- und Video-Inhalte zu
generieren. Kann mehrere Bitraten in einen Stream kodieren (SureStream), erzeugt
RealAudio oder RealVideo Dateien. Verfügbar für Windows, Mac und Linux/Unix:
eingeschränkte Basisversion kostenlos, Plusversion $150.
RealSlideshow: Tool um Audio mit Bilder, Texten und Überblendungen zu einer
Diashow
zusammenzufügen.
Steuerung
und
Synchronisierung
mit
SMIL.
Basisversion kostenlos.
RealPlayer: Spielt Real Formate, inkl. SMIL sowie MPEG Video und mp3 ab,
automatisches Update bei fehlenden Codecs. Basisversion kostenlos, Plusversion
$30.
RealJukebox: Anwendung um Musiktitel abzuspielen und zu verwalten. Aufnahme und
Konvertierung von Audio in Real Formate, mp3, wav, Windows Media Audio.
Wiedergabe von fast allen Audioformaten, Abspielen von .pls und .m3u Playlisten.
Datenbankfunktion zur Verwaltung von Titeln, ID3v1 sowie ID3v2 werden
11
verarbeitet. Automatische Erzeugung von Playlisten aufgrund vom Benutzer
definierbarer Kriterien. Brennen von Audio CDs. Basisversion kostenlos.
Microsoft Windows Media(http://www.microsoft.com/windows/windowsmedia/ ):
Windows Media Services: Server für live und on-demand Inhalte, verwendet das MMS
(Microsoft Media Server) Protokoll, mehrere Bitraten in einer Datei möglich.
Geeignet für die Übertragung von Audio, Video und Multimedia, Synchronisierung
mit ASF Skript Befehlen. Server ist in Betriebssystem Windows 2000 Server
integriert, ein Update für Windows NT 4 ist kostenlos erhältlich.
Microsoft Media Encoder: Encoder um live oder on-demand Inhalte zu generieren. Kann
mehrere Bitraten in einen Stream kodieren (Multi Bitrate), erzeugt Windows Media
Video (WMV) oder Windows Media Audio (WMA) Dateien. Als Eingangsquelle
können nicht nur Livequellen und Mediadateien verwendet werden, sondern auch die
Bildschirmoberfläche (Screen Capture). Kostenlos für Windows verfügbar.
Microsoft Media Author: Tool um Audio mit Bilder und Texten zu einer Diashow
zusammenzufügen. Steuerung und Synchronisierung mit ASF Skript Befehlen.
Kostenlos erhältlich.
Windows Media Advanced Script Indexer: Tool um Skript Befehle und Marker in eine
Windows Media Datei einzubetten. Ermöglicht die Realisierung von Untertiteln,
Einbettung und Aufruf von URLs. Kostenlos für Windows verfügbar.
Windows Media Player: Spielt alle Microsoft Formate sowie die meisten Windows
Formate ab. Ab Version 7.x ist unter anderem eine Playlisten-Funktion und eine
Musikdatenbank zur Verwaltung von Titeln integriert. Kostenlos erhältlich für
Windows.
Apple QuickTime (http://www.apple.com/quicktime/ ):
QuickTime / Darwin Streaming Server : Server für live und on-demand Inhalte im
QuickTime Format, verwendet RTSP. Geeignet für die Übertragung von Audio und
Video. „Playlist Broadcaster“ überträgt vorhandene QuickTime Dateien automatisch
in definierbarer Reihenfolge. In Mac OS X integriert und als Open Source Projekt für
Linux (Darwin Server) erhältlich.
12
Marktübersicht und Stand der Technik - Streaming Systeme
QuickTime: Player für QuickTime Dateien und viele andere Formate, unter anderem
Flash 4, MPEG-1, DV. Kostenlos erhältlich für Mac und Windows.
QuickTime Pro: Funktionen wie QuickTime, zusätzlich Bearbeitung, Erstellung und
Kodierung von Filmen in verschiedenen QuickTime Formaten. Erstellen von
Diashows, Hinzufügen von Effekten, Automatisierung mit AppleScript. Verfügbar
für Windows und Mac, $30.
Nullsoft SHOUTcast (http://www.shoutcast.com/) :
SHOUTcast Distributed Network Audio Server (DNAS): Server für live und on-demand
Audio Inhalte im mp3-Format. Pro Server wird nur eine Bitrate unterstützt, es wird
HTTP Streaming verwendet. Songtitel und Links können in den Stream eingbettet
werden. Kostenlos verfügbar für Windows, Linux, Unix.
SHOUTcast DSP Plug-in: Plug-in für Winamp, welches die Enkodierung der LiveSignale in das mp3-Format realisiert. Songtitel und URLs können in den Stream
eingebettet werden. Kostenlos erhältlich für Windows.
Winamp: Player für mp3 und andere Formate. Durch Plug-in Struktur vielseitige
Verwendung möglich, u.a. als Encoder für mp3-Streams. Verfügt über PlaylistFunktionen und Minibrowser, in dem die in einem Stream eingebetteten URLs
angezeigt werden. Kostenlos erhältlich für Windows.
RealNetworks und Microsoft bieten die umfassendsten Streaming-Lösungen an. Für das
Microsoft-System spricht, dass es im Grunde kostenlos erhältlich ist, leicht skalierbar ist
und die Codecs (inzwischen) eine gute Bild- und Tonqualität erreichen. RealNetworks
Produkte sind zwar teuer, sind aber funktional durchdachter, funktionieren besser und
stabiler und sind einfacher zu bedienen als die Microsoft Produkte. Insgesamt kann mit
Produkten von RealNetworks im Moment eine bessere Qualität der Streams zu erreichen
ist.
Das Nullsoft System ist sehr beliebt, da es kostenlos erhältlich ist, wenig Ressourcen
verbraucht und einfach zu handhaben ist und als passendes Gegenstück zu Winamp an
dessen Beliebtheit anknüpfen kann. Darüber hinaus sind für fast alle Plattformen und
Betriebssysteme kostenlose, kleine Player erhältlich. Nachteile des Systems sind jedoch,
dass HTTP nicht ein für Streaming optimiertes Protokoll und dementsprechend unsicher
13
und ineffizient ist. Weiterhin ist die Klangqualität von mp3-Streams niederer Bandbreite
schlechter als vergleichbare Streams von Microsoft oder Real.
QuickTime Live-Streaming hat im Moment noch keine große Bedeutung erlangt.
QuickTime Dateien stehen meist nur on-demand oder zum Download zur Verfügung.
2.1.2 Professionelle Automationssysteme für Webcasting
Es gibt einige professionelle Automationssysteme auf dem Markt, die für die
Verwendung in größeren Radiostationen konzipiert sind.1 Ein Teil dieser Systeme
ermöglicht über zusätzliche Programme oder Plug-ins die Automation von WebcastingAngeboten. Viele der Systeme realisieren nur die grundlegendsten Möglichkeiten, so
dass damit Webcasting im Sinne dieser Arbeit kaum möglich ist. Diese Schwachstellen
haben dazu geführt, dass nach Auskunft von Oliver Reuther, SWR3 online, große
Radiostationen eigene Software entwickeln, um ein attraktives Webcasting realisieren zu
können.2
Nachfolgend werden kurz einige Systeme vorgestellt, die zumindest grundlegende
Webcasting- Funktionalitäten anbieten.
DAVID GmbH (http://www.david-gmbh.de):
DigAS ist ein modular aufgebautes Automationssystem, das speziell für den Einsatz in
Sendern mit hohem Wort und Nachrichtenanteil entwickelt wurde. Es sind Module für
alle Stationen der Verarbeitungskette vorhanden, von Erstellung über Planung bis
Ausspielung der Beiträge. Die Beiträge werden in einem Redaktionssystem verwaltet. Es
gibt mehrere Module, die Webcasting-Angebote unterstützen. Mit DigaWEB Tools
können on-demand Inhalte automatisch generiert und im Internet publiziert werden. Das
DigaWebSystem ermöglicht die Generierung von dynamischen Webseiten, die mir
Inhalten aus dem Redaktionssystem gefüllt sind und Informationen über das aktuelle
Programm enthalten. Das Live-Programm kann gestreamt werden, die Gestaltung von
Side-Channels ist möglich. Die Anzeige von multimedialen Zusatzinformationen kann
mit einem zentralen Content Management und Planungs-System realisiert werden.
1. Das Kriterium für die Einordnung in den „professionellen“ Bereich sind dabei die jeweiligen Angaben
zu Referenzprojekten.
2. Informationsgespräch am 30.5.2001, SWR3 online, Baden-Baden
14
Marktübersicht und Stand der Technik - Professionelle Automationssysteme für Webcasting
AUDIO EXPORT GmbH (http://www.audioexport.de/ ):
RADIOMAX und CoRA32 Internet sind zwei unterschiedlich dimensionierte RadioAutomationslösungen, die ein Veröffentlichung von programmbegleitenden Zusatzdaten
im Internet unterstützen. Einfache Interaktionen, wie zum Beispiel Playlist-Recherche
sind möglich. Bei beiden Systemen ist ein Datenbanksystem integriert, welches die
Verwaltung von Audio- sowie Zusatzdaten unterstützt.
mediatron GmbH (http://www.mediatron.de/ )
Das Hauptprodukt AirControl NT ist eine konventionelle Radio-Automationssoftware,
die automatisches Ausspielen sowie Unterstützung für den Live-Betrieb bietet. Das
Plug-in
WebShow
realisiert
die
Veröffentlichung
von
programmbegleitenden
Zusatzinformationen wie Titel, Interpret und Grafiken.
DRS Systemtechnik (http://www.drs2006.com/ )
DRS2006 ist ein Radio-Automationssystem, mit dem Ausspielung und Planung von
Playlisten organisiert werden können. Der Real Time Playlist Generator veröffentlicht
eine Liste mit den zuletzt gespielten Titeln im Internet.
RCS (http://www.rcsworks.com/ )
Vom Marktführer im Bereich Radio Software gibt es viele Anwendungen, die zusammen
den gesamten Bedarf an Broadcast-Software in einem Radiosender decken. Die
wichtigsten Produkte, die auch für Webcasting verwendet werden können sind: Selector
assistiert und automatisiert die Planung und Gestaltung von Playlisten gemäß dem
Senderformat. Master Control ist das Automationssystem für Ausspielung der Playlisten
und Live-Betrieb. MusicBase ist eine Datenbank, die eine Vielzahl an Informationen
über jeden erfassten Titel und Interpreten bietet. RCS RadioShow ist eine komplette
Webcasting Lösung, die mit Selector und Master Control zusammenarbeitet. RadioShow
beinhaltet den RCS Media Manager, ein CMS zur Verwaltung und Planung von
multimedialen Daten. Die Daten werden in einem speziellen Stream synchron zum
Audiostream im Internet veröffentlicht. SplitStream ermöglicht das zielgruppengerechte
Aufteilen von Streams zu Werbeblöcken. Weiterhin gibt es eine Skriptsprache, die für
das einfache Erstellen von DHTML Animationen konzipiert ist. Die Animationen
werden ebenfalls vom Media Manager verwaltet. Mit iSelector ist seit kurzem ein
innovatives Produkt auf dem Markt, denn es wird nicht das terrestrisch gesendete
15
Programm einfach im Internet dupliziert, sondern es wird ein eigenständiges Programm
gestreamt. Der Inhalt des Streams richtet sich nach dem Senderformat und den in
Selector erzeugten Playlisten. Der Hörer kann per Klick auf seinen iSelector Player
entscheiden, ob er vom aktuellen Interpreten mehr, weniger oder gar keine Titel mehr
hören möchte. Das Programm passt sich so dem Geschmack des Hörers an, es basiert
aber trotzdem noch auf dem Senderformat. Es handelt sich also nur um einen virtuellen
Live-Stream, da es im Grunde on-demand Streaming ist.
2.1.3 Sonstige Tools
Es gibt frei erhältliche Tools, mit denen die Verarbeitung und Organisation von mp3Dateien erleichtert wird. Im Rahmen der praktischen Umsetzung dieser Arbeit wurden
einige Tools eingesetzt und getestet. Die nützlichsten Tools werden nachfolgend kurz
vorgestellt:
ID3-TagIt (http://www.id3-tagit.de/ ):
Mit ID3-TagIt können die ID3v1 und ID3v2 Tags von mp3-Dateien ausgelesen und
bearbeitet werden. Es lassen sich nicht nur eine Datei sondern viele Dateien auf einmal
bearbeiten. Besonders nützlich ist die Funktion, Dateinamen in Tag-Informationen
umzuwandeln oder Tags in Dateinamen zu wandeln. Dadurch wird eine Konsistenz von
Dateinamen und Tag-Informationen über den ganzen Bestand an mp3-Dateien hinweg
ermöglicht.
MP3 Track Maker (http://www.heathcosoft.com/ )
Der Track Maker kann mp3-Dateien in einzelne Dateien aufteilen und eignet sich damit
für das Kürzen von zu langen Sendemitschnitt-Dateien (bei Mitschnitten, die über das
Ende der Sendung hinweg gehen) und das Extrahieren von einzelnen Titeln oder
Beiträgen aus einer mp3-Datei.
MP3-Musicstation (http://www.mp3-musicstation.de/ )
Die MP3-Musicstation ist eine netzwerkfähige relationale Datenbank zur Verwaltung
einer sehr großen Anzahl an mp3-Dateien. Die Datenbank erfasst alle Informationen aus
den ID3 Tags und bietet zusätzlichen Platz für weitere Daten, wie Texte und Grafiken.
Den Titeln werden eindeutige IDs zugewiesen, so dass auch doppelt vorhandene Stücke
zuverlässig verwaltet werden. Titel können nach allen Kriterien gesucht, sortiert und
16
Voraussetzungen für Automation - Technische Voraussetzungen
ausgewählt werden. Eine Mulit-User Umgebung wird unterstützt, jeder Benutzer kann
eigene Einstellungen und Bewertungen speichern. Es können automatisch Playlisten
nach definierbaren Kriterien sowie Hitlisten erstellt werden. Es sind mehrere PlayerModule integriert, Vorhören und Überblendungen sind möglich. Die Software ist „...also
vor allem für diejenigen geeignet [...], die mehrere hundert oder gar mehrere tausend
Dateien im Zugriff haben wollen - das bekommt man mit der MP3-Musicstation recht
gut hin.“1
2.2 Voraussetzungen für Automation
2.2.1 Technische Voraussetzungen
Es gibt einige technische Grundbedingungen für die erfolgreiche Einführung von
Automationssystemen, die im folgenden skizziert werden:
Digitalisierung:
Alle Daten, die in einem Webcasting-System automatisiert verwendet werden sollen,
haben in einem digitalen Format vorliegen. Audio, Video, Bilder, Grafiken und Texte
müssen nicht nur digital erfasst und gespeichert werden, sondern auch in ein Format
umgewandelt werden, das vom Automationssystem verarbeitet werden kann. Eine
Konvertierung ist nötig, wenn bereits vorhandene Daten von einem StandardDatenformat in das proprietäre Format des Automationssystem gewandelt werden
müssen.
Speicherung:
Eine Speicherung aller Daten hat so zu erfolgen, dass sie vom Automationssystem
jederzeit zugreifbar sind, entweder lokal oder über ein Netzwerk. Es muss ein
eindeutiger Zugriff auf Datenobjekte möglich sein, d.h. das zum Beispiel zwischen
unterschiedlichen Versionen eines Titels – Single Version oder Maxi Version –
unterscheidet werden kann. Dies kann durch Namenskonventionen, Song IDs oder ein
Datenbanksystem geschehen. Überdies sollte ein Vorschau der Daten möglich sein, so
dass zum Beispiel Videos auf jedem Arbeitsplatzrechner betrachtet werden können.
1. Kuri, Virtueller Plattenschrank, 2000
17
Dafür muss unter Umständen eine zweite Version der Medien in geringere Auflösung
gespeichert sein oder eine on-the-fly Enkodierung stattfinden.
Synchronisierung:
Es sind Schnittstellen zu implementieren, die eine Synchronisierung der einzelnen
Aktionen eines Webcasting-Systems ermöglichen. Das heißt, dass zum Beispiel das
Ausspiel-System Informationen an das Push-System übergeben kann, damit ein
zeitlicher Zusammenhang der präsentierten Audio- und Textdaten erreicht wird.
2.2.2 Inhaltliche Aspekte
Inhaltliche Voraussetzungen eines automatisierten Programms müssen erarbeitet und
bedacht werden, um effektiv ein attraktives Programm zu erhalten:
Sender-Format:
Hans-Dieter Hillmoth beschreibt die Funktion eines Sender-Formats unter anderem
folgendermaßen: „Das Format eines Senders legt alle Zutaten des Programms
verbindlich fest. Im Format-Stylebook sind diese Zutaten definiert: Welche Musik wird
gespielt? Wieviel Musik gibt’s bei diesem Programm? Wie ändert sich die Musik über
den Tag? Wie wird die Musik verpackt? Wieviel Wort enthält das Programm?“.1 Das
Format gibt demnach Antworten auf die Fragen, die bei der Programmierung eines
Sendeablaufs gestellt werden müssen. Da außerdem definiert wird, wann welche Inhalte
gesendet werden, können diese aufbereitet werden, so dass sie dem Automationssystem
rechtzeitig zur Verfügung stehen. Aus dem Format können auch Regeln abgeleitet
werden, die bei der Erfüllung von Musikwünschen vom Automationssystem beachtet
werden müssen.
Content Management System:
Ein CMS ist vor allem für die Verwaltung von größeren Medienbeständen
unumgänglich. Es ermöglicht mit Hilfe einer Datenbank den inhaltlichen Überblick über
die archivierten Medien und damit eine inhaltliche Planung und Gestaltung von
Sendungen. Medien, die nicht textbasiert sind, müssen indiziert und beschrieben werden,
damit eine textbasierte Suche möglich ist.2
1. Hans-Dieter Hillmoth in: Clef, Radio Marketing, 1995, S. 81
18
Voraussetzungen für Automation - Voraussetzungen an den Internetauftritt
2.2.3 Voraussetzungen an den Internetauftritt
Webcasting erfordert die dynamische Präsentation von Inhalten über das Internet. Um
dies zu realisieren, müssen einige Anforderungen erfüllt werden:
Dynamische Webseiten:
Für die effektive Gestaltung von Webcasting-Angeboten ist die Generierung von
dynamischen Webseiten essentiell. Die Seiten sollten mit Hilfe einer Datenbank
verwaltet werden, wobei die Datenbank über eine Schnittstelle verfügt, mit der vom
Automationssystem eine Manipulierung der Daten erfolgen kann.
Spezielle Server:
Ein Webserver allein ist für Webcasting nicht ausreichend. Das Live-Streaming von
Audiodaten erfordert spezielle Hochleistungs-Server, die zur besseren Lastverteilung auf
unterschiedlichen Rechnern laufen sollten. Manche Push-Systeme erfordern ebenso die
Installation von entsprechenden Servern.
Leistungsfähiges Netzwerk:
Für Streaming-Anwendungen wird ein leistungsfähiges Netzwerk benötigt, mit einer
möglichst schnellen Verbindung ins Internet. So ist zum Beispiel eine 2 Mbps Leitung
bereits mit 35 Streams von 56 kbps ausgelastet. Durch Multicast-fähige Netzwerke kann
dieser Bandbreiten-Bedarf verringert werden.1 Ein leistungsfähiges Netzwerk ist auch
innerhalb des Senders notwendig, da hochaufgelöste Audio- und Videodaten bearbeitet
und fehlerfrei gesendet werden müssen.
2.2.4 Produktionsrichtlinien
Die Produktionsrichtlinien eines Senders sind genaue Vorgaben an die sich alle
Inhaltslieferanten zu halten haben. Sie beschreiben die – meist technischen –
Spezifikationen der jeweiligen Medien und stellen somit sicher, dass eine einheitliche
(technische) Qualität der Medien erreicht wird und diese ohne weitere Bearbeitung in
den Sendeablauf eingegliedert werden können. Bei der Verwendung eines
Automationssystems sind Produktionsrichtlinien besonders wichtig, da bei deren
Einhaltung die Medien direkt in das System übernommen werden können. Im Rahmen
2. Detaillierte Anforderungen an ein CMS sind bei Wegner/Bachmeier, Streaming Media, 2000, S. 168 ff.
beschrieben.
1. Siehe auch Wegner/Bachmeier, Streaming Media, 2000, S. 94 ff.
19
dieser Arbeit sind grundlegende Produktionsrichtlinien für Radio GLF entstanden, die
im Laufe des Semesters ständig verbessert und erweitert wurden. Die in Anhang A
abgedruckten Produktionsrichtlinien sind auf dem Stand vom Ende Sommersemester
2001.
2.3 Konzepte im Bereich Webcasting
2.3.1 Einführung
In den folgenden Kapiteln geht es um bereits realisierte Konzepte im Bereich
Webcasting sowie um innovative Konzepte, die in Zukunft realisiert werden könnten.
Webcasting bezieht sich dabei, wie in der gesamten Arbeit, auf die in1.3 erläuterte
Definition.
Die Studie „Internet V“ von Arbitron und Edison Media Research beruht auf der
Analyse von 412 repräsentativ ausgewählten Websites amerikanischer Radiostationen,
auf Telefoninterviews mit 3005 Teilnehmern des Arbitron Panels sowie auf einem
Online-Fragebogen, den 14703 Personen ausfüllten. Die Studie untersucht auf
umfassende Weise den Ist-Zustand der Nutzung von Webcasting und Internet
Angeboten.
Insbesondere
Verbraucherverhalten
werden
untersucht,
die
um
Bereiche
mögliche
E-Commerce,
Erlösmodelle
Werbung
für
und
Webcasting
aufzuzeigen.1 Im Rahmen dieser Studie wurde auch eine Analyse der Inhalte und
Features auf Websites von (amerikanischen) Radiostationen durchgeführt. Die
Ergebnisse dieser Analyse sind in dem Bericht „Radio Station Web Site Content: An InDepth Look“ zusammengefasst.2
Dieser Bericht eignet sich gut, um bereits bestehende und realisierte Konzepte im
Bereich Webcasting zu erörtern, so dass im folgenden Kapitel Auszüge aus diesem
Bericht präsentiert und kommentiert werden. Der Bericht beruht allerdings nur auf der
Analyse des amerikanischen Radiomarktes und sagt deshalb nichts über die Features auf
Webseiten europäischer oder deutscher Sender aus. Deshalb werden zusätzlich die
Internet Angebote von einigen deutschen Sendern analysiert, um eine gewisse
Vergleichsmöglichkeit zu haben. Die Auswahl der Sender, deren Webseiten untersucht
1. Arbitron, Internet V, 2000, S. 1ff.
2. Arbitron, Radio Station Web Site Content, 2000, S. 2
20
Konzepte im Bereich Webcasting - Bestehende Konzepte
werden, ist dabei nicht repräsentativ. Da nur bestehende Konzepte aufgezeigt werden
sollen und nicht die Anzahl an existierenden Umsetzungen dieser Konzepte, wird bei der
Auswahl der Radiostationen willkürlich vorgegangen.
2.3.2 Bestehende Konzepte
2.3.2.1Datensammlung
Die folgende Tabelle basiert auf einer Tabelle aus dem oben erwähnten Bericht „Radio
Station Web Site Content: An In-Depth Look“.1 Sie ist jedoch gekürzt, da alle Features,
die nicht in das Gebiet „Webcasting und Automation“ gehören aus der ursprünglichen
Tabelle entfernt wurden. Die aufgelisteten Features können jeweils den Bereichen
„Programmbegleitende Informationen“, „Interaktion“, „Service/Information“ und
„Programm“ zugeordnet werden.
#
Web Site Feature
% radio
station Web
sites with
each
feature**
Rank of interest
in each Web site
feature*
1
Information on and pictures of DJs
78
9
2
Schedule of programming
63
8
3
Ability to listen to the radio station
59
1
4
To contact or e-mail the DJs and personalities
53
10
5
Information about local concerts
50
2
6
To enter contests
49
4
7
Information on local weather
44
7
8
To buy products or services (other than station
merchandise)
14
22
9
Opportunity to vote on whether songs are good or not
13
6
10
Traffic information
12
11
11
To see an advertiser's products
9
21
12
Titles and artists of songs recently played on the station
6
3
13
"Side channels" (Additional Internet-only audio
provided on the site)
1
14
*Rank based on % Very Interested in finding each feature on a radio station Web site (from Pop-Up Survey);
**Base: All radio station Web sites (n=412) (from Content Analysis)
1. Arbitron, Radio Station Web Site Content, 2000, S. 10
21
Quelle: Arbitron, 2000, Radio Station Web Site Content, S. 10
Abbildung: 2-1 Tabelle Radio Station Web Site Features
Nachfolgend werden die Webseiten einiger deutscher Radiostationen auf die
vorhandenen Features untersucht. Sind Features aus der obigen Tabelle vorhanden, so
wird dies mit einem X vermerkt. Besonderheiten oder neue Features werden im
nachfolgenden Text erläutert. Die Nummern in Spalte 1 beziehen sich auf die Features
der obigen Tabelle und geben deren Nummer an.
#
SWR3
dasWebrad
io.de
Bayern
3
Big FM
DASDIN
G
Antenn
e1
WDR2
Sunshin
e live
1
X
X
X
X
X
X
X
X
2
X
X
X
X
X
X
X
X
3
X
X
X
X
X
X
-
X
4
X
X
X
X
X
X
-
X
5
X
-
X
X
X
X
-
X
6
X
X
X
X
X
X
-
X
7
X
-
X
-
-
-
-
-
8
X
-
X
X
-
X
-
X
9
X
-
X
-
-
-
-
-
10
X
-
X
-
-
X
X
-
11
-
-
-
-
-
-
-
X
12
X
-
-
-
X
-
X
X
13
10
-
-
-
3
-
-
-
U
R
L
www.swr3.
de
www.daswebra
dio.de
www.baye
rn3.de
www.bigfm.de
www.dasdin
g.de
www.ante
nne1.de
www.wdr
2.de
www.suns
hinelive.de
E
xt
ra
s
Ausführlich
e Titelinfos,
StudioFeedback,
Musikwüns
che,
Spycams,
SMS
Service,
Chat, ElchTV
Reines
Internetradio,
Downloads von
Titeln
unbekannter
Bands
Nachricht
en
stündlich
ondemand
abrufbar,
Webcams
SMS
Titelinfos
und Kauf,
Forum,
Chat,
Communit
y, Flyer
Maker,
OnlineSpiele
Newstikker,
Musikrecher
che, Forum,
Chat,
Spycams,
Netz-Charts,
On-demand
Clips
Ondemand
Clips
Games,
Forum,
SMSDienste
Quelle: eigene Erhebungen im August 2001
Abbildung: 2-2 Tabelle Features deutsche Radiosender Websites
22
2.3.2.2Ergebnisse
Wie aus den obigen Tabellen hervorgeht, können deutsche Radiostationen in Bezug auf
ihre Webseiten durchaus mit amerikanischen Stationen mithalten, zumindest was die
Vielfalt der Features angeht. Über eine quantitative Verteilung der Features, d.h. wie
viele deutsche Radiostationen ein Feature anbieten, kann jedoch nichts gesagt werden,
da es sich nicht um eine repräsentative Auswahl handelt.
Wie im vorigen Kapitel schon angedeutet, lassen sich die meisten Features den
Bereichen „Programmbegleitende Informationen“, „Interaktion“, „Service/Information“
und „Programm“ zuordnen.
Unter
„Programmbegleitende
n Informationen“ sind
zum Beispiel Features
wie Anzeige von Titel
und
Interpret
des
aktuellen
sowie
vergangener
Titel,
Informationen
aktuellen
oder
Interpreten
Anzeige
Konzertdaten
aktuellen
zum
der
des
Interpreten
einzuordnen. In den
Abbildung: 2-3 SWR3 Player
kommerziellen Bereich
dieser Features fällt auch die Anzeige von beworbenen Produkten in den Werbepausen,
oder die Möglichkeit, den aktuellem Titel gleich online zu bestellen. Die Website von
SWR3 ist bei der Anzeige von „Programmbegleitenden Informationen“ vorbildlich
(s.Abbildung 2-3), der Hörer kann aus einem sehr reichlichen Angebot an Informationen
auswählen, zusätzlich zu den oben genannten können zum Beispiel auch
Chartpositionierungen des aktuellen Interpreten angezeigt werden. Bei SWR3 wie auch
23
bei Big FM werden „Programmbegleitenden Informationen“ nicht nur auf der Website
angeboten, sondern die aktuellen Titeldaten können auch per SMS zum Hörer gelangen.
Abbildung: 2-4 Big FM
SMS
Die Anzeige von Informationen und Bildern der Moderatoren, DJs und sonstiger
Mitarbeiter eines Senders kann statisch sein, also auf einer speziellen Team-Seite des
Senders; dann ist dieses Feature in den Bereich „Programm“ einzuordnen. Die Anzeige
kann jedoch auch dynamisch erfolgen, wie dies bei SWR3 der Fall ist: dort erscheint auf
der Website immer ein Bild mit den Moderatoren der aktuellen Sendung und ist somit
den „Programmbegleitenden Informationen“ zugehörig. Zum Bereich „Programm“
gehört auch das Sendeschema oder Links zu Themen aus den aktuellen Sendungen. Die
Vorstellung von unbekannten Interpreten mit zum Beispiel dem Angebot ein Titel zum
Probehören herunterzuladen kann auch dem „Programm“ Bereich zugeordnet werden.
In den Bereich „Service/Information“ sind die Features Verkehrsnachrichten,
Wetterberichte oder sonstige Nachrichten einzugliedern.
„Interaktion“ ist ein sehr wichtiger Bereich an Features, da hier die Hörer aktiv in das
Programm eingebunden werden und mit Chats oder Community Features ein
Gemeinschaftsgefühl aufgebaut werden kann. „Interaktion“ ist weiterhin die
Möglichkeit, Titel zu bewerten, Titelwünsche zu äußern, an Preisrätseln teilzunehmen
oder Feedback ins Studio oder zum Sender zu geben. Online-Spiele und Features wie
beispielsweise der „Flyer Maker“ von Big FM sind Interaktionsmöglichkeiten, die zwar
nicht direkt mit Webcasting in Zusammenhang stehen, aber dennoch die jeweiligen
Websites attraktiver für die Hörer macht.
24
Die Möglichkeit über das Internet die Radiostation als Audiostream empfangen zu
können lässt sich nicht einem Bereich zuordnen. Sie ist vielmehr die Grundlage dafür,
das Online-Angebot des Senders als Webcasting zu bezeichnen. Ebenso sind „SideChannels“ ein typisches Merkmal für Webcasting, bei traditionellem Rundfunk sind
höchstens im Programm enthaltene Regionalfenster damit vergleichbar. Die
Ausgestaltung eines „Side-Channels“ kann sehr unterschiedlich erfolgen. In der
einfachsten Version ist nur der Audiostream zu hören, es können jedoch auch alle
Features des Hauptkanals nochmals für die Nebenkanäle realisiert sein.
Die Websites der beiden analysierten Sender des SWRs, SWR3 und DASDING, sind
positive Beispiele für die Umsetzung von Webcasting Angeboten. Die Webauftritte sind
sehr aufwendig gestatelt, es sehr viele Features umgesetzt, der Nutzer wird aber nicht mit
zu vielen Informationen auf einmal überlastet. Nach Angaben von Oliver Reuther,
SWR3 online, war SWR3, bzw. damals noch SWF3, einer der erste Sender in
Deutschland, der einen Audiostream und programmbegleitende Daten auf seiner Website
veröffentlichte. Aufgrund der Erfahrungen konnte die SWR3 Website zur erfolgreichsten
und aufwendigsten Radiowebsite in Deutschland aufgebaut werden.1
DASDING war von Anfang an als interaktiver
und multimedialer Sender geplant und „..
vernetzt Radio, Fernsehen, und Internet zu
einem digitalen, interaktiven Mulitmedium mit
hohem Wort- und Musikanteil“.2 Insbesondere
wird Wert auf Interaktionsmöglichkeiten gelegt,
die Hörer/Zuschauer können jederzeit per
Email, Fax und Chat mit der Redaktion und
anderen
Zuschauern
Musikwünsche,
Kritik
kommunizieren,
und
Abbildung: 2-5 DASDING Playliste
Anregungen
loswerden. Die Inhalte der Sendungen werden durch Inhalte auf der Webseite ergänzt,
wie zum Beispiel durch Bilder, Hintergrundinformationen und Links. Die Hörer/
1. Informationsgespräch am 30.5.2001, SWR3 online, Baden-Baden
2. SWR, pressefuzzis, 2001, S. 3
25
Zuschauer werden so mit einem umfassenden Webcasting-Angebot versorgt (s.
Abbildung 2-5).
In dieser Arbeit wurden nur die Websites von Radiostationen auf deren Angebot an
Features untersucht, andere Institutionen, die ebenfalls Webcasting betreiben, sind nicht
erfasst worden. Grundsätzlich können die angebotenen Features der Radiowebsites mit
anderen Inhalten auch in anderen Bereichen angeboten werden. Corporate Radio,
Business TV, Schulfernsehen oder –radio können alle erfassten Features zur
Kommunikation, Interaktion und Information einsetzen und davon profitieren.
2.3.3 Innovative Konzepte
2.3.3.1Services/Information
Im Bereich Services/Information gibt es einige Möglichkeiten, das vorhandene Angebot
mit neuen Leistungen anzureichern.
Denkbar ist zum Beispiel, dass ein Hörer sich für bestimmte Titel zu einem
Benachrichtigungs-Service anmelden kann. Die Titel können die Lieblingsstücke des
Hörers sein, es können Börsennachrichten, Wettervorhersagen, Veranstaltungstipps oder
sonstige Beiträge sein, eben alle Titel und Beiträge, die der Hörer nicht verpassen
möchte. Kurz bevor ein solcher vorgemerkter Titel gespielt wird bekommt der Hörer
eine Benachrichtigung per Instant Messenger (ICQ, AIM, Yahoo IM), SMS oder Email,
so dass genügend Zeit bleibt, um das (Web-)Radio anzustellen. Dieser Dienst setzt ein
datenbankgestütztes Webinterface voraus, mit dessen Hilfe der Hörer die Titel an- und
abmelden kann. Die Datenbank muss dabei alle verfügbaren Titel, Beiträge oder
Beitragsarten kennen und mit dem Automationssystem synchronisiert sein.
Das Angebot an programmbegleitenden Informationen kann sinnvoll erweitert werden.
Insbesondere bei Nachrichten oder anderen Wortbeiträgen gibt es viele visuelle
Informationen, die synchron zum Audiostream präsentiert werden können, wie zum
Beispiel Börsenkurse, Wetterkarten, Links oder Bilder. Während der Sendung von
Werbespots können Grafiken und Links des jeweiligen beworbenen Produkts angezeigt
werden. Die Inhalte sollten möglichst automatisch eingefügt werden, ohne dass ein
redaktioneller Aufwand auf Senderseite entsteht. Dies kann durch Content Provider
26
Konzepte im Bereich Webcasting - Innovative Konzepte
geschehen, Content Syndication oder intelligente Softwareagenten, ein entsprechend
leistungsfähiges Content Management System (CMS) ist dafür Voraussetzung.
In bisherigen Konzepten ist eine meist nur Titelrecherche möglich, die als Ergebnis den
Namen eines Titels liefert sowie möglicherweise den Zeitpunkt, zu dem er gespielt
wurde. Mit einer automatischen Generierung und Indexierung von on-demand Inhalten
wäre es nun möglich, den Titel oder Beitrag sofort anzuhören. Zum einen hat der Hörer
dann die Bestätigung, dass es sich um den richtigen Titel handelt und er kann zum
andern den Titel nochmals anhören. Eine Realisierung dieses Konzepts erfordert
ebenfalls ein leistungsfähiges CMS, entsprechende Encodersoftware sowie die Klärung
der dabei entstehenden rechtlichen Fragen.
Eine Ausweitung der Dienste auf mobile Endgeräte ist insbesondere im Hinblick auf die
zukünftige UMTS Generation an Geräten sinnvoll. So können nicht nur der
Audiostream, sondern insbesondere die programmbegleitenden Informationen für den
mobilen Einsatz (WAP, i-Mode) aufbereitet werden. Das Wünschen von Titeln, ebenso
wie Abstimmungen können per SMS realisiert werden.
2.3.3.2Interaktion
In Zukunft sind weitergehende Möglichkeiten der Interaktion denkbar, da eine
Generation aufwächst, für die das Radio nicht nur ein passives Nebenbei-Medium ist,
sondern Radio als interaktives Medium kennenlernt und entsprechende Webcasting
Angebote auch nutzt. Musikwünsche und Grüße sind nicht mehr nur per Telefon, Fax
oder Email möglich, sondern auch per Netmeeting oder Instant Messenger. Dabei
können mit der eigentlichen Nachricht auch Bilder, Audio- und Videoinformationen
mitgesendet werden, die dann später über den Sender zu sehen, bzw. hören sind.
Es ist bei manchen Sendern bereits möglich, Titelwünsche per Webinterface zu äußern.
Die Wünsche werden dann von der Redaktion manuell in den Sendeablauf eingeplant.
Mit einer Kopplung an das Musikplanungssystem und Automationssystem könnten
Wünsche
automatisch,
ohne
redaktionellen
Aufwand
gespielt
werden.
Das
Musikplanungssystem muss dann mit Hilfe von Regeln und Sendeuhr darüber
entscheiden, ob der Wunschtitel dem Programmformat entspricht und gespielt werden
kann. Somit wird verhindert, dass zum Beispiel Rocktitel während einer Technosendung
gespielt werden. Webserver, Automationssystem und Musikplanungssystem müssen
27
über geeignete Schnittstellen verfügen, damit eine Umsetzung gelingt. Auch hier gibt es
rechtliche Fragen, die noch nicht eindeutig geklärt sind.
Durch Interaktion mit dem Nutzer kann das Webcasting-Angebot in einigen Bereichen
personalisiert werden. Bei normalen Webseiten ist dies nichts Neues mehr, der Hörer
könnte mit der gleichen Technik beim Aufruf der Seite seinen favorisierten Player mit
der passenden Bandbreite und dem favorisierten Layout, Skin oder Themenangebot
präsentiert bekommen. Während Werbeblöcken bekommt der Hundebesitzer Werbung
für Hundenahrung und der Vogelbesitzer Werbung für Mauserhilfe. Soweit ist noch nicht
viel Interaktion vom Hörer/Nutzer gefordert. Doch es kann auch der Inhalt des gesamten
Streams, also zum Beispiel das Musikangebot, personalisiert werden. Der Hörer kann
dabei jeden gespielten Titel bewerten, so dass das System mit der Zeit den persönlichen
Geschmack des Hörers kennenlernt und nur noch Titel spielt, die zu seinem Geschmack
passen könnten. Für den Nutzer hört es sich wie eine normale Radiosendung an, es ist
allerdings kein Livestreaming mehr, sondern – für den Hörer unbemerkt – on-demand
Streaming auf Basis einer personalisierten Playlist.
2.3.3.3Anwendungsbereiche
Die Technologien, die in dieser Arbeit erläutert und diskutiert werden können auch in
einer anderen Umgebung als dem Internet oder Intranet eingesetzt werden. Prinzipiell
eignet sich jedes Medium, mit dem Audio-, Video- und Textdaten transportiert werden
können und ein Rückkanal mit genügend Leistung existiert.
In vielen Musikgeschäften können die Kunden eine Auswahl an CDs an Terminals
anhören. Die CDs werden dann von einem CD-Wechsler abgespielt, es stehen die
üblichen Bedienungsfunktionen eines CD-Spielers zur Verfügung. Diese Systeme
könnten durch ein Laden-internes Webcasting System ersetzt werden, die Terminals
enthalten dann keine CD-Wechsler und CDs, sondern einen Rechner mit Touchscreen
und Soundkarte, der über das Netzwerk mit dem Server verbunden ist. Den Kunden
können verschiedene Kanäle angeboten werden, wie „Neuheiten“, „Sonderangebote“,
etc. aber auch die Möglichkeit, beliebige auf dem Server verfügbare Titel anzuhören. Zu
den Titeln werden dann während des Anhörens alle auf der eigentlichen CD verfügbaren
Informationen (Texte, Komponist, Texter, Produzenten, Bilder, Grafiken,...) präsentiert.
Für den Kunden besteht zusätzlich die Möglichkeit, Zusatzinformationen abzurufen oder
28
Konzepte im Bereich Webcasting - Ergebnisse
Links zu Angeboten des gleichen Interpreten, der gleichen Epoche oder zu ähnlichen
Genres zu folgen. Es stehen weiterhin alle Möglichkeiten eines Online-Shops zur
Verfügung, mit dem Unterschied, dass vorhandene CDs sofort im Laden abgeholt
werden können und Audioangebote aufgrund der Intranet-Umgebung mit genügend
Bandbreite in bester Qualität gestreamt werden können. Das Musikgeschäft kann alle
Möglichkeiten des User-Trackings mit diesem System ausnutzen und sein Angebot
entsprechend optimieren.
Ein weiterer Einsatzbereich eines Webcasting-Systems ist in modernen Hotels möglich.
Diese verfügen meist über ein interaktives TV-System, bei dem ein Rückkanal
vorhanden ist, es können Rechnungen angezeigt oder Dienstleistungen bestellt werden.
Die TV Geräte auf den Zimmern dienen auch zum Radioempfang. Mit einem Interface
zu diesem TV-System können Hotels ihren Gästen einen oder mehrere hotelinterne
Webcasting Kanäle anbieten, die über die Leistungen und Angebote des Hotels, über
lokale Veranstaltungen oder Sehenswürdigkeiten informieren.
Auf ähnliche Weise ist der Einsatz eines Webcasting-Systems auch in modernen
Flugzeugen möglich. Das bordinterne Unterhaltungssystem besteht für jeden Passagier
aus einem Monitor, einer Fernbedienung und einem Kopfhöreranschluss. Als
Unterhaltungsangebot gibt es eine Reihe an Video- und Audiokanälen, sowie
verschiedene Videospiele. Die Audiokanäle können zu einem interaktiven WebcastingAngebot erweitert werden, bei dem alle typischen Features zur Verfügung stehen. In das
Webcasting-Programm können Inhalte aus dem Bordmagazin einfließen, sowie
Informationen über den aktuellen Flug, Anschlussflüge, Wetterinformationen, oder
Informationen zum Zielort. Diese Informationen werden bereits jetzt schon an die
Passagiere weitergegeben, sie müssen also nur noch für den Webcasting-Einsatz
aufbereitet werden.
2.3.4 Ergebnisse
Wie in den vorangegangenen Kapiteln geschildert, gibt es einige Features und
Anwendungsbereiche, die noch nicht in der Praxis existieren und angewandt werden.
Technisch sind nur kleine Probleme zu lösen, da die grundlegenden Techniken schon
vorhanden sind und weiterbenützt werden können. Der redaktionelle Aufwand, der
geleistet werden muss, um sinnvolle Inhalte anzubieten, ist dagegen sehr hoch und stellt
29
ein Problem dar, das nur mit leistungsfähigen Multimedia Content Management
Systemen gelöst werden kann.
Nach Meinung von Marcus Schuler, Redaktionsleiter von DASDING, ist die
Entwicklung in Deutschland noch nicht so weit. Die Hörer/Nutzerzahlen von Webradios
sind relativ niedrig, weshalb sich Webcasting mit einer Vielzahl an Features für
Radiostationen nicht lohnt.1
Interessant ist die Anwendung von Webcasting-Technologien in Bereichen, bei denen
bereits eine breitbandige Vernetzung zur Verfügung steht, wie zum Beispiel bei Intranets.
1. Informationsgespräch am 30.5.2001, SWR, Baden-Baden
30
Ausgangsbedingungen der Umsetzung -
3
Praktische Umsetzung
3.1 Ausgangsbedingungen der Umsetzung
Der praktische Teil der vorliegenden Arbeit wurde im Rahmen des Internet Hochschul
Senders „Radio GLF“ der FH Furtwangen geleistet. Im Sommersemester 2001 überträgt
GLF jeden Dienstag eine Sendung live ins Internet, es handelt sich dabei im
wöchentlichen Wechsel jeweils um eine WebRadio und eine WebTV Sendung, die in den
Studios des Fachbereichs Digitale Medien live produziert werden. Das dabei entstehende
Material wird bei der praktischen Umsetzung dieser Arbeit verwendet und wird vor
sowie nach den Live-Sendungen dem Testpublikum aus GLF Hörern, bzw. Nutzern rund
um die Uhr serviert.
Für die technische Umsetzung konnte die gesamte Infrastruktur des DM-Studios benützt
werden, insbesondere standen ein Windows 2000 System, ein Linux System mit zwei
Shoutcast Servern, RealServer und Webserver, sowie ein Windows 2000 Server System
mit Webserver, FTP-Server, Shoutcast Server und Windows Media Services zur
Verfügung. Außerdem konnte noch ein reiner Arbeitsplatz-Rechner mit Windows NT 4
Server für Verwaltungs- und Testzwecke benutzt werden. Alle Systeme sind über eine
100 Mbit Netzwerkkarte an das Studio LAN angebunden.
Durch aktive Teilnahme an den wöchentlichen Sendungen konnten Schwachstellen der
jeweiligen Realisierungsstufen erkannt werden und sogleich Anregungen für deren
Behebung gewonnen werden.
In den Kapiteln 3.2.1 bis 3.2.4 werden sehr ausführlich die einzelnen Stufen der
Umsetzung geschildert. Zu jeder Realisierungsstufe gibt es ein Kapitel mit den
Konzepten und den Zielen der jeweiligen Stufe, die als Basis für die jeweils im
darauffolgenden
Kapitel
beschriebene
technische
Umsetzung
dienen.
Daran
anschließend folgt immer ein Kapitel, in dem auf die Besonderheiten im praktischen
Einsatz der jeweiligen Stufe hingewiesen wird. Abschließend zu jeder Realisierungsstufe
gibt es ein Kapitel, welches die Probleme aufzeigt, die während des Betriebs entstanden
sind und außerdem mögliche Lösungen dieser Probleme andeutet.
31
3.2 Die einzelnen Stufen der Realisierung
3.2.1.1Radio GLF on Air 24/7
„People who listen to a radio station online spend more time on that station’s
Web site and visit that site more often.“1
Wie am Anfang der Arbeit schon erwähnt sendet Radio GLF mit Beginn des
Sommersemesters 2001 jeden Dienstag von 19:00 Uhr bis 21:00 Uhr ein live Programm.
Während der ganzen anderen Zeit herrscht „Funkstille“, lediglich im Archiv stehen
vergangene Sendungen und Beiträge für den on-demand Aufruf und zum Download zur
Verfügung.
Da zum Sommersemester 2001 vom WPV Webcasting verstärkt Werbe- und
Marketingmaßnahmen eingesetzt werden, ist damit zu rechnen, dass Nutzer auch
während der sendefreien Zeit auf die Webseite zugreifen. Nicht optimal für einen
Internet Radiosender ist es, wenn die meiste Zeit über kein Live-Stream vorhanden ist.
On-demand Inhalte sind dafür kein Ersatz. Zum einen muss der Nutzer sich dafür zuerst
bis zum Archiv durchklicken und dann entscheiden, was er denn hören möchte - einen
direkten Link zu einem Live-Stream gibt es nicht. Zum andern ist der Konsum von ondemand Inhalten ein anderes Erlebnis wie das Hören von Radio. Ein Radio schaltet man
ein, sucht vielleicht noch einen Sender und hört einfach zu. Wahrscheinlich wird zu
diesem Zeitpunkt ein anderes Musikstück oder ein anderer Beitrag gesendet als beim
letzten Einschalten. Es ist auch nicht nötig, dass man sich sein Programm aus einzelnen
Musik- und Wortbeiträgen von Hand zusammensetzen muss.
Das Ziel der Realisierungsstufe 1 ist es, einen jederzeit empfangbaren „live“
Audiostream in die Webseite zu integrieren. Dadurch wird die Attraktivität der Website
erhöht und Radio GLF als Radiosender etabliert. Denn: Zu einem Radiosender gehört,
wie oben geschildert, dass er auch live sendet.
Doch was soll gesendet werden? Welchen Inhalt soll das „Rund-um-die-Uhr“ Programm bekommen? Radio GLF verfügt zu diesem Zeitpunkt weder über ein direkt
1. Arbitron, Internet V, 2000, S. 18
32
Die einzelnen Stufen der Realisierung - Realisierungsstufe 1
verwendbares
und
sendetaugliches
Archiv,
noch
gibt
es
ein
detailliertes
Programmformat. Dienstags, während den Live-Sendungen entscheidet das jeweilige
Sendungsteam bzw. die Redaktion über die Musik, die gespielt wird und wie viele
Beiträge und Moderationen es gibt. Der zeitliche Wechsel und Rhythmus der einzelnen
Programmbeiträge ist nicht geregelt, ebenso wenig wie der Einsatz von Jingles.
Generelle Richtlinie ist es, das Programm passend für die Zielgruppe „Studenten
allgemein und die der FH Furtwangen im Besonderen“ zu gestalten. Dabei hat jede
Sendung das Ziel „...relevante Informationen und Unterhaltung zu verbinden
(Infotainment).“1
Musik ist der am meisten nachgefragte Programmtyp bei Streaming Audio
Anwendungen2 und ist auch am einfachsten zu realisieren. In der Realisierungsstufe 1
besteht deshalb das automatisierte Programm aus ca. 200 Musiktiteln. Die Titel sind bunt
gemischt, mit einer Betonung auf Hits der 80er und 90er Jahre, sowie einigen aktuellen
Titeln. 200 Titel sind ausreichend, denn „100 gilt in der Branche als absolutes Minimum,
üblich sind 150 bis 300“.3 Das Programm entspricht damit in etwa einen kommerziellen
Radiosender, wie zum Beispiel Antenne 1, Antenne Bayern oder Radio Regenbogen. Bei
diesen Sendern ist die Zielgruppe so breit ausgelegt, dass die Radio GLF Zielgruppe
darin enthalten ist. Auf die besonderen Wünsche und Eigenschaften der Radio GLF
Zielgruppe wird damit zwar nicht besonders eingegangen, jedoch steht bei Stufe 1 die
schnelle und einfache Umsetzung im Vordergrund. Ein genauer abgestimmtes
Programm, welches und Eigenständigkeit von Radio GLF unterstützt ist für spätere
Realisierungsstufen vorgesehen.
3.2.1.2Technische Umsetzung Realisierungsstufe 1
Im folgenden Abschnitt wird auf die technischen Besonderheiten der Umsetzung
eingegangen. Die Details der verwendeten Software werden nur insoweit vorgestellt, wie
diese für die Umsetzung eine Rolle gespielt haben oder Unklarheiten in der zur
jeweiligen Software gehörenden Dokumentation beseitigt werden müssen.
1. Schäfer-Schönthal, A., WebRadioBeschreibung, 2001
2. Arbitron, The Need for Speed, 2001, S. 14
3. Hammerstein, Konstantin von, 2000, Hit für Hit, S. 109
33
Um den laufenden Semesterbetrieb mit wöchentlichen Sendungen nicht zu gefährden
wurde die vorhandene Sende-Infrastruktur für die Realisierungsstufe 1 nicht verändert.
In den vergangenen Semestern hat sich ein Lösung etabliert, mit der technisch gesehen
die größte Anzahl an potenziellen Hörern erreicht werden kann. Die potenzielle
Hörerschaft gliedert sich dabei in die in Abbildung 3-1 dargestellten Gruppen:
Zielgruppe
max. Bandbreite
Modem-Benutzer
56 kbps/33.6 kbps,
ISDN-Benutzer
64 kbps,
LAN- oder DSL-Benutzer
ca. 80 kbps bis 500 kbps.
Abbildung: 3-1 Vorhandene Bandbreiten Radio GLF Zielgruppe
Um für alle Gruppen einen ausreichenden Kompromiss in Bezug auf Audioqualität und
Bandbreitenverbrauch anzubieten, werden während der Live-Sendungen zwei mp3Streams mit 24 kbps und 56 kbps zur Verfügung gestellt. Zusätzlich werden meist noch
Streams im Real oder Microsoft--Format angeboten. Nach Informationen von
Live365.com werden Audiostreams mit Bandbreiten von 32 kbps oder weniger am
häufigsten genutzt.1 (Live365.com ist einer der erfolgreichsten Anbieter von Internet
Sendern im mp3-Format).2
Als erster Encoder arbeitet in dieser Struktur ein Winamp, der normalerweise das im
Tonstudio erstellte Live-Programm analog über Line-in der Soundkarte erhält.3 Aus
diesem Signal wird dann der Audiostream erstellt. Alternativ können aber auch
Audiofiles in der Winamp-Playlist angeordnet und abgespielt werden. Hierbei wird das
Signal nicht analog gewandelt sondern es wird beim Abspielen direkt digital dem
Encoder-Plug-in zugeführt.4 Auf diese Art kann die bestmöglichste Qualität des fertigen
Audiostreams ermöglicht werden. Winamp wurde in erster Linie als Abspieler von mp3Dateien entwickelt. Die große Verbreitung und ständige Weiterentwicklung hat
1. 75% der Live365.com Nutzer hören Streams mit 32 kbps oder weniger, siehe auch Live365.com
Newsletter, Memorial Day Weekend Edition, 26.5.2001
2. Siehe Arbitron, Pressemitteilung, 29.1.2001
3. Download unter http://www.winamp.com/
4. zur Plug-in Struktur von Winamp: Siehe „Technische Umsetzung Realisierungsstufe 2“ auf Seite 45.
34
inzwischen zu einem stabil laufenden Produkt geführt, so dass nichts gegen einen
Einsatz von Winamp in der ersten Realisierungsstufe spricht, zudem Winamp als
Freeware kostenlos erhältlich ist.
Musiktitel sind im mp3-Format sehr zahlreich verfügbar, die Dateien benötigen nur
wenig Speicherplatz, denn sie sind im Vergleich zu unkomprimierten Audiodateien um 8
bis 12 Mal kleiner. Somit lässt sich mit Titeln im mp3-Format sehr effizient ein
Musikarchiv zusammenstellen. Das Musikarchiv besteht in dieser Stufe aus einem
Dateiverzeichnis auf dem Encoder-Rechner (PCS-15) in dem sich ca. 200 mp3-Dateien
befinden. Aus diesen 200 Titel wird dann eine Playlist erstellt, die Winamp endlos und in
zufälliger Reihenfolge abspielt. Den schematischen Aufbau zeigt Abbildung 3-2 auf
Seite 36. Zunächst einige Erläuterung zu den einzelnen Komponenten.
Winamp 1 mit Playlist ist die eigentliche Quelle des Audiostreams. Winamp dekodiert
die mp3-Dateien und sendet die Daten an das DSP Plug-in. Dieses übernimmt die
Enkodierung des Signals in der gewünschten Bitrate und schickt das Ergebnis an den
Shoutcast-Server.1
Außerdem tauscht es via XML Metadaten mit dem Server aus. Das Plug-in ist zur Zeit
nur
für
Windows/Intel
Plattformen
erhältlich,
die
Forderung
nach
Plattformunabhängigkeit kann damit nicht erfüllt werden.2 Es gibt derzeit leider noch
keine Alternative dazu.
Das DSP Plug-in funktioniert nur, wenn ein mp3-Codec installiert ist. Dieser Codec
übernimmt die Enkodierung des Signals in das gewünschte mp3-Format. Ab Windows
98 wird der Codec automatisch mit der Installation des Windows Media Players
mitinstalliert. Sollte der Codec nicht vorhanden sein, gibt das Plug-in eine
Fehlermeldung aus. In diesem Fall ist es am einfachsten, die MS NetShow Services zu
installieren, da dabei automatisch auch der mp3-Codec eingerichtet wird.3 Die von
Microsoft installierten Codecs sind
kostenlos erhältlich, bzw. im Betriebssystem
enthalten. Sie basieren auf dem original Fraunhofer Algorithmus und stellen somit eine
1. Informationen über Plug-in und Server sowie deren Installation gibt es in der dazugehörigen
Dokumentation, Nullsoft, SHOUTcast Documentation, 1999, S. 1-13
2. unter http://www.shoutcast.com/download/broadcast.phtml#plugdownload
3. zu erhalten unter http://mskyus.www.conxion.com/msdownload/netshow/3.01/x86/en/nstools.exe
35
56 kbps-Stream
An Clients
DSP-Plug-in Æ
Winamp 1
56 kbps-Stream
+ Playlist
Server
liefert
56 kbpsStream
Shoutcast
Shoutcast
Loopback-Server
Relay-Server 56k
DSPPlug-in
24
kbpsStream
Connected auf
Loopback-Server
und spielt 56k
Stream ab
Winamp 2
Shoutcast
Server 24k
24 kbps-Stream
Audiosignalfluß
Rechner: PCS-15
Abbildung: 3-2 Schema Realisierungsstufe 1
36
An Clients
Rechner: glfservice
qualitativ hochwertige mp3-Kodierung zur Verfügung, allerdings sind sie aus
Lizenzgründen in ihrer Funktion beschränk. Die erste Einschränkung besteht darin, dass
bei der Enkodierung von Audiosignalen eine maximale Bitrate von 64 kbps verwendet
werden kann. Für Streaming- Anwendungen ist dies im Moment noch ausreichend.
Gravierender ist deshalb die zweite Beschränkung auf nur eine Instanz des Codecs zur
gleichen Zeit. Das bedeutet, dass zwei Programme, die den Codec verwenden wollen,
nicht zur gleichen Zeit lauffähig sind, da jedes von ihnen eine Instanz des Codecs
erzeugen möchte. Existiert bereits eine Instanz, so meldet der Codec ein „belegt“ an das
rufende Programm, welches dann eine Fehlermeldung ausgibt. Rufendes Programm im
Fall von Shoutcast mp3-Streaming ist das DSP Plug-in. Möchte man, so wie es sich bei
Radio GLF eingebürgert hat, zwei verschiedene Bitraten zur Verfügung stellen, sind
zwei DSP Plug-ins notwendig, die dann zwei Instanzen des mp3-Codecs erfordern.
Es gibt für dieses Problem mehrere Lösungsmöglichkeiten: Einfachste und beste
Möglichkeit ist die Installation des voll funktionsfähigen mp3-Codecs – genannt „MPEG
Layer-3 Audio Codec (Professional) - vom Fraunhofer Institut für Integrierte
Schaltungen (IIS).1 Diese Version erlaubt mehrere Instanzen und Bitraten bis zu 320
kbps. Insbesondere unter Windows 2000 kann es angeblich zu Problemen kommen,
wenn der Professional- Codec – bei bereits vorhandenem normalen mp3-Codec – als
zweiter mp3-Codec installiert werden soll.
In diesem Fall gibt es eine zweite Lösungsmöglichkeit: Man verwendet keine zwei
original Nullsoft DSP Plug-ins, sondern nur eines und ruft damit auch nur eine Instanz
des Codecs auf. Für den zweiten Stream kann auf ein DSP Plug-in zurückgegriffen
werden, das keinen externen mp3-Codec benötigt, sondern der Codec bereits in das
Plug-in integriert ist. Ein solches Plug-in ist zum Beispiel das Oddcast DPS Plug-in, das
den LAME mp3-Algorithmus verwendet.2 LAME (= Lame ain’t no mp3 encoder) ist ein
Open-Source Projekt und so frei erhältlich. Die damit erreichte Audioqualität des
Streams ist geringer als die Qualität, die mit dem original Fraunhofer mp3-Codec erzielt
werden kann.
1. Download unter http://www.iis.fhg.de/audio/
2. mehr Informationen und Download unter http://www.oddsock.org/
37
Deshalb gibt es noch eine relativ aufwendige dritte Möglichkeit: Das zweite DSP Plug-in
läuft auf einem anderen Rechner und bekommt sein Eingangssignal entweder über das
Netzwerk - der schematisch Aufbau wäre dann ähnlich wie in der Realisierungsstufe 1 oder analog über Line-in der Soundkarte.
Auf dem Senderechner von Radio GLF war der Fraunhofer Professional Codec
problemlos zu installieren, so dass diese Lösung verwendet wird um zwei verschiedene
Bitraten zu erzeugen. In Realisierungsstufe 1 ist das DSP Plug-in von Winamp 1 folgend
konfiguriert: Shoutcast-Server ist in diesem Fall der auch im Schema dargestellte
Loopback Server, der lokal auf dem selben Rechner wie das DSP Plug-in läuft. Als IP ist
deshalb „localhost“ ausreichend, der Port kann auf dem standardmäßig eingestellten
Wert 8000 verbleiben. Weiterhin sind Einstellungen im Format-Auswahlfenster von
Bedeutung. Hier wird die Bitrate des zu erzeugenden Streams eingestellt, in diesem Fall
56 kbps, die Samplerate beträgt 22050 Hz im Stereo-Modus.
Der vom DSP Plug-in erzeugte 56 kbps mp3-Stream wird vom Loopback Server
empfangen und steht dann am eingestellten Port den Winamp-Clients zur Verfügung.
Ein Shoutcast-Server ist eine Anwendung, auf die den vom DSP Plug-in eingehenden
Stream nach Bedarf vervielfacht und an verbundene Winamp-Clients schickt. Erst
dadurch wird Live-Übertragung und –Empfang von mp3-Daten möglich. Weiterhin
sammelt der Server Daten über Clientverbindungen und gespielte Titel, die dann über ein
XML-Interface zur Auswertung weitergeleitet werden können. Ferner ermöglicht der
Server das, im Vergleich zum on-demand mp3-Streaming über den Webserver, sicherere
Streaming von on-demand Inhalten. Der Shoutcast-Server entspricht der Forderung nach
Plattformunabhängigkeit, es sind Versionen für mehrere Betriebssysteme erhältlich.1 Der
Server sowie das DSP Plug-in sind ebenfalls Freeware.
Der Shoutcast-Server wird in unserem Fall als „Loopback Server“ verwendet, seine
Aufgabe besteht lediglich darin, den Stream an Winamp 2 zu liefern, der daraus einen 24
kbps Stream generiert.
Die Konfiguration von Winamp 2 sieht folgendermaßen aus: Als Eingangssignal wird
der 56 kbps Stream des Loopback Servers verwendet. Zugang zu diesem Stream
1. unter http://www.shoutcast.com/download/
38
bekommt man, indem man in die „Open location“ Box von Winamp die Adresse und den
Port des Servers einträgt, in diesem Fall „localhost:8000“. Die Konfiguration des DSP
Plug-ins funktioniert analog zu der von Winamp 1. Die Bitrate wird auf 24 kbps, 22050
Hz, Mono eingestellt. Für IP und Port gibt man die entsprechenden Werte ein, die zur
Konfiguration des 24 kbps Shoutcast-Servers passen. Da sich dieser Server auf einem
anderen Rechner befindet, muss es diesmal eine tatsächlich existierende IP Adresse sein.
Wenn man dann mit Winamp 2 auf „Play“ geht und das DSP Plug-in aktiviert wird der
empfangene 56 kbps Stream in einen 24 kbps Stream umgewandelt und an den Server
geschickt.
Die zwei Shoutcast-Server, auf die dann die Hörer über das Internet zugreifen können,
laufen bei Radio GLF z.Zt. auf einem Linux-Rechner. Für die Realisierungsstufe 1 ist der
56k Server als Relay-Server konfiguriert. Dies bedeutet, dass der Server keine direkte
Verbindung zu einem DSP Plug-in zulässt, der Stream wird stattdessen von einem
anderen Shoutcast-Server abgeholt. Dazu müssen dem Relay-Server die Zugangsdaten
des Ursprung-Servers bekannt gemacht werden. Im Prinzip werden dabei in der
Serverkonfiguration dieselben Werte (IP Adresse und Port) eingetragen, wie wenn ein
Winamp den Stream abspielen würde. Der Relay-Server hat also eine ähnliche Funktion
wie Winamp 2, allerdings wird nichts mehr kodiert. Der Server sendet mit derselben
Bitrate, mit der er empfängt.
Der 24k Server ist als Standard Shoutcast-Server konfiguriert, so dass er den 24 kbps
Stream von Winamp 2 empfangen kann. Zu beachten ist, dass beide Server auf
demselben Rechner laufen und somit auch die gleiche IP Adresse haben. Der
Unterschied ist die Portadresse, diese ist für jeden Server verschieden. In diesem Fall ist
der 56k Server über Port 9000 zu erreichen, der 24k Server über Port 7000.
3.2.1.3 Der praktisch Einsatz von Realisierungsstufe 1
Der praktische Einsatz dieser ersten Stufe der Automatisierung ist eigentlich problemlos.
Winamp 1 sollte in den „Repeat“ und „Shuffle“ Modus gestellt werden, damit die Titel in
der Playlist endlos und in unterschiedlicher Reihenfolge abgespielt werden.
39
Für einen reibungslosen Start des Systems – zum Beispiel nach einem Neustart des
Rechners – ist die Reihenfolge wichtig, mit der die einzelnen Winamps und Server
gestartet werden. Folgende Auflistung gibt die entsprechende Reihenfolge wieder:
1. Loopback - Server
2. 24k Server und 56k Relay - Server (diese können immer akiviert bleiben.)
3. Winamp 1, Abspielmodus
4. Konnektieren des DSP Plug-ins von Winamp 1
5. Winamp 2, Abspielmodus
6. Konnektieren des DSP Plug-ins von Winamp 2
3.2.1.4Probleme
Das System funktioniert im Gesamten recht gut. Der vorgestellte Aufbau war über die
Dauer mehrerer Semester hinweg bei nicht-automatisierten Sendungen im Einsatz. Es
gibt jedoch einige Problemstellen:
Mehrfache mp3-Kodierung: Das 56 kbps- Signal ist deutlich schlechter als das
Eingangssignal (welches analog oder digital in Form von mp3-Titeln zugeführt
wird).1 Dieses 56kbps Signal dient dann als Quelle für den 24 kbps Encoder, was
effektiv zu einem noch schlechteren Stream führt. Wenn man diesen Stream mit
einem 24 kbps Stream vergleicht, der eine qualitativ hochwertige Quelle hat sind
qualitative Unterschiede hörbar.
Höherer Ressourcenverbrauch: Winamp 2 dekodiert den 56 kbps Stream um ihn
anschließend wieder zu kodieren. Der Dekodierungsvorgang verbraucht unnötig
Prozessorleistung.
Hinzu
kommt
der
Loopback
Server,
der
ebenfalls
Prozessorleistung wie auch Arbeitsspeicher benötigt. Insgesamt entsteht dadurch
eine relativ gering Mehrbelastung des Systems, die unter normalen Umständen
vernachlässigt werden könnte. Wenn aber auf demselben Rechner bei LiveSendungen zusätzlich ein MS Media Encoder und ein RealProducer laufen ist das
System bis in den Grenzbereich ausgelastet. Systemressourcen sollten also wo
möglich eingespart werden.
1. Vgl. Stoll, G., 1999, Broadcast@Internet, S. 32-52
40
Keine „One Button-“ Lösung: Das System erfordert bestimmtes Wissen über
Funktionalitäten und Aufbau um es problemlos bedienen zu können. Die Praxis hat
gezeigt, dass das System nicht von jedem sofort gestartet werden kann, da die oben
beschriebene Reihenfolge eingehalten werden muss. Ein einzelner Button oder Link
zum Starten des Systems wäre wünschenswert.
Keine richtige Webcasting Lösung: In Stufe 1 wird nur der Audioteil eines WebcastingSystems automatisiert. Zusatzdienste
und –Informationen stehen nicht zur
Verfügung, ebenso wenig wie automatisierte Interaktionsmöglichkeiten.
3.2.2.1„Jetzt läuft“ und „Die letzten 10“
„A full 60 percent of radio station Web site visitors said they were very
interested in the ‘titles and artists of songs recently played on the station’ on
radio station Web sites.”1
Nach erfolgreichem Testlauf der Realisierungsstufe 1 folgt mit Stufe 2 eine Erweiterung
in der Funktionalität sowie einigen Änderungen in der technischen Umsetzung. Die im
vorigen Kapitel genannten Probleme werden dabei weitgehend gelöst.
Inhaltlich ändert sich das Konzept des automatisierten Sendeablaufs in der
Realisierungsstufe 2 nur wenig. Das Programm besteht immer noch aus den 200
Musiktiteln, die jetzt aber mit alten Sendungen und Beiträgen aus dem Archiv gemischt
werden. Aus den vergangenen Semestern waren acht komplette GLF Radiosendungen
archiviert, zusätzlich werden die aktuellen Sendungen aus dem Sommersemester 2001
hinzugefügt – sobald sie für das Archiv vorliegen. Eine typische Radiosendung ist dabei
ein Mitschnitt bzw. Archivdatei des DSP Plug-ins, der während der Live-Sendung
erstellt wird. Es sind somit alle Moderationen, Beiträge und Musiktitel fertig abgemischt
und an einem Stück – ohne Pause oder Unterteilungen – vorhanden. Im Durchschnitt ist
eine Sendung etwa 120 Minuten lang. Sind von den jeweiligen Sendungen noch Beiträge
in eigenständigen Dateien, also in Form von mp3-Dateien vorhanden, so werden auch
diese der Playlist hinzugefügt. Mit Verlauf des Sommersemesters 2001 sind fast alle in
1. Arbitron/Edison Media Research, Radio Station Web Site Content, 2000, S. 13
41
diesem Semester entstandenen Beiträge als Einzelstücke im Archiv vorhanden und
können weiterverwertet werden.
Verbesserungen sind noch im Sound des automatisierten Programms möglich. Bei den
Live-Sendungen von Radio GLF werden die Beiträge, Moderationen und Musiktitel mit
dem Mischpult zusammengemischt, so dass flüssige Übergänge zwischen den einzelnen
Programmelementen entstehen. Musikstücke werden nicht ganz ausgespielt, wenn sie
gegen Ende immer leiser werden, sondern das neue Stück wird schon abgefahren,
solange das vorige Stück noch läuft. Nach Beiträgen wird lückenlos in Musik
übergegangen, folgt danach eine Moderation, kann der Moderator über das ausklingende
Stück sprechen. Durch diese Vorgehensweise entsteht ein lebendiges Klangbild, und es
gibt – idealerweise – keinen Moment, in dem der Lautstärkepegel unter einen gewissen
Wert fällt. Da es praktisch keine „Stille“ gibt, haben die Zuhörer keine Zeit um den
Sender zu wechseln. Zusätzlich wird das abgemischte Audiosignal noch durch einen
Dynamikkompressor
bearbeitet,
der
eine
weitere
Anhebung
des
gesamten
Lautstärkepegels gestattet. Insbesondere bei niederen Bitraten führt dies zu einer
Verbesserung der Tonqualität beim Hörer.
Während des automatisierten Programms werden diese Klangverbesserungen bisher
nicht durchgeführt, da das Signal von Winamp abgespielt und direkt gesendet wird. Hat
zum Beispiel ein Musikstück einen sehr leisen Anfang oder eine lange Ausblendung am
Ende, so spielt Winamp dennoch das ganz Stück ab. Aufgrund des Qualitätsverlust durch
die Enkodierung, die für Streaming notwenig ist, werden leise Passagen nicht oder nur
sehr schlecht wiedergegeben. Beim Empfänger kommen also nur Stille und
Störgeräusche an. Ein weiteres Problem ist, dass Musiktitel oder Beiträge oft einen
unterschiedlichen Lautstärkepegel haben. Bei Live-Sendungen korrigiert dies der
Tontechniker, bei automatisierten Sendungen muss auch dies automatisch funktionieren.
Ein Ziel der Realisierungsstufe 2 ist es deshalb auch, das Klangbild des automatisierten
Programms an das Niveau der Live-Sendungen anzupassen, es soll ein professioneller
Klang entstehen.
Die erweiterte Funktionalität besteht im Grunde aus zwei neuen HTML-Seiten, die
gemäß ihrem Inhalt mit „jetzt läuft“ und „Playlist“ bezeichnet werden. Mit der „jetzt
läuft“ - Seite wird der Name des aktuellen Titels sowie der aktuelle Interpret in die Radio
42
GLF Webseite integriert. Außerdem gibt es einen Link auf die „Playlist“- Seite, die
weitergehende Informationen enthält. Zusätzlich zu Name und Interpret des aktuellen
Titels sind noch die Dauer des Titels, sowie Name und Interpret des folgenden Titels
vermerkt. Ferner gibt es auf dieser Seite eine Liste der letzten zehn gespielten Titel, die
mit Namen und Interpret aufgeführt werden.
Wie für jede andere zu erstellende Webseite sind auch für diese zwei Seiten einige
Vorüberlegungen nötig, um ein optimal angepasstes Design der Seiten zu erreichen.
Insbesondere die Aufteilung und Darstellung der Informationen sind von Bedeutung. Die
Gestaltung hinsichtlich Farben und Schriftarten hat sich ohnehin an die bereits
vorhandene Webseite von Radio GLF zu halten, so dass in diesem Bereich keine
Überlegungen notwendig sind.
Wie schon erwähnt gibt es zwei neue HTML-Seiten. Eine Aufteilung der Informationen
auf zwei Seiten ist nicht nur sinnvoll, sondern im Fall der bestehenden Radio GLF
Webseite auch notwendig. Auf der Seite ist nur noch eine sehr kleine Fläche vorhanden,
die sowohl während des automatisierten Betriebs als auch während der Live-Sendungen
frei zu verwenden ist (siehe Pfeil in Abbildung 3-3). Die für den Besucher der Seite
Abbildung: 3-3 Radio GLF Webseite, Anfang SS 2001
43
interessanteste Information in Bezug auf den Audiostream sind Name und Interpret des
aktuellen Titels. Diese Informationen passen genau in die noch freie Fläche hinein. Ein
Besucher der GLF Hompage kann so direkt – ohne weitere Klicks – sehen, was er hören
könnte, wenn er den Stream einschalten würde. Gefällt ihm, was er sieht, wird er
wahrscheinlich einschalten. Weiterhin kann es den Fall geben, dass Hörer nicht über die
Radio GLF Webseite zum GLF Stream gelangt sind, sondern zum Beispiel über dem
Stream des Internet Hochschul Radio Verbunds (IHR). Möchten diese Hörer wissen, was
gerade läuft, haben diese auch einen Grund die GLF Website zu besuchen, wo sie die
gewünschten Informationen unverzüglich bekommen.
In der kleinen Box mit den „jetzt läuft“ Informationen, befindet sich euch ein Link zur
„Playlist“ Seite, die in einem neuen, in der Größe angepassten Fenster erscheint. Diese
Seite ist so gestaltet, dass sie zum einen für Hörer interessant ist, die nebenbei über
längere Zeit dem Stream zuhören und nicht immer die ganze Webseite sehen möchten,
weil sie vielleicht nebenbei noch surfen oder arbeiten. Das relativ kleine „Playlist“
Fenster kann auf dem Desktop an die Seite geschoben werden und nur bei Bedarf in den
Vordergrund gebracht werden. Zum andern ist diese Seite für Hörer interessant, die
Radio GLF noch nicht kennen. Sie können sehen, welche Titel in der letzten Zeit gespielt
wurden und so Rückschlüsse auf das Programm ziehen. Sind die gespielten Titel nach
ihrem Geschmack, ist es wahrscheinlich, dass sie den Stream einschalten werden.
Wie schon erwähnt, enthält die „Playlist“ Seite die „die letzten 10“-Liste mit den zehn
zuletzt gespielten Titeln und Interpreten. Eine Beschränkung auf zehn Titel ist sinnvoll,
da sonst die Seite zur Darstellung mehr Platz auf dem Desktop beansprucht und auch die
Informationstiefe sehr groß wird. Bei einer durchschnittlichen Dauer von 3,5 min. pro
Titel reicht die Liste eine gute halbe Stunde in die Vergangenheit. Da aber auch
komplette GLF Sendungen aus dem Archiv gesendet werden und somit in die Liste
aufgenommen werden, gibt die „die letzten 10“-Liste Auskunft über einen Zeitraum von
mehreren Stunden. Am unteren Ende der Seite befindet sich ein Hinweis auf die letzte
Aktualisierung der Seite. Daran kann erkannt werden, ob die Seite wirklich aktuell ist
und bestätigt somit die Gültigkeit der enthaltenen Informationen. Bei den Informationen
auf der Seite handelt es sich um zeitkritische Informationen, d.h. sie sind nur innerhalb
eines bestimmten Zeitrahmens gültig. Durch technische Ausfälle (Server, Netzwerk,
44
Winamp, ...) sowie durch das manchmal unvorhersehbare Cache-Verhalten der Browser
ist eine synchrone, rechtzeitige Darstellung der Seite nicht immer gewährleistet. Eine
Zeile auf der Seite mit der genauen Angabe von Erstellungsdatum und Erstellungszeit
erhöht also die Glaubwürdigkeit dieser Seite, da erkannt werden kann, dass sie
tatsächlich aktuell ist. Dies wirkt sich wiederum positiv auf die Akzeptanz der Seite aus.
Auch bei Stufe 2 kommt ausschließlich Winamp als Player zum Einsatz. Mit seiner Plugin Struktur und den zahlreichen kostenlos erhältlichen Plug-ins lassen sich die o.g. Ziele
– theoretisch – in die Praxis umsetzen. Auf die dabei entstandenen Schwierigkeiten wird
in Kapitel 3.2.2.4 eingegangen. Für das bessere Verständnis der technischen Umsetzung
sind Kenntnisse über die Plug-in Struktur von Winamp nötig, die folgend erläutert wird.1
Input
Interaktion
Eine
Input Plug-in
General Plug-in
des
An erster Stelle in Winamp steht das Input Plugin. Input Plug-ins ermöglichen das Abspielen
verschiedenen
Medienformaten.
Je
nachdem, was für ein Plug-in installiert ist kann
Winamp nicht nur mp3-Dateien, sondern auch
Output
DSP Plug-in
Darstellung
Audiosignalflusses zeigt Abbildung 3-4.
von
Visual. Plug-in
grafische
wav-Dateien, AIFF-Dateien, AU-Dateien oder
sogar Videodateien im MPEG oder AVI Format
abspielen. Dabei entsteht ein Bitstrom, der den
Output
Output Plug-in
nachfolgenden Plug-ins zur Verfügung steht.
Winamp Plug-in
Struktur
Das Visualization Plug-in bekommt seine
Eingangsdaten direkt vom Input Plug-in. Die
Abbildung: 3-4 Signalfluss duch
Winamp Plug-ins
Daten sind die Basis für die Berechnung
grafischer Effekte und Visualisierungen. Diese
Plug-in hat keinen Einfluss auf das Audiosignal, es liefert nur eine optische Darstellung
derselben.
1. vgl. auch Nullsoft, Writing Plug-ins, 1999
45
Das DSP Plug-in bezieht seine Daten ebenfalls direkt vom Input Plug-in. Plug-ins dieser
Art verändern normalerweise das Audiosignal, so gibt es zum Beispiel Module, die die
Funktion von Equalizern oder Dynamikkompressoren übernehmen. Es kann jeweils nur
ein einziges DSP Plug-in aktiviert sein, ein Wechsel des Plug-ins ist während der
Laufzeit möglich. Das Shoutcast Source Plug-in ist auch ein DSP Plug-in, es verändert
das Audiosignal jedoch nicht, sondern sendet es lediglich an den Shoutcast-Server.
Das Output Plug-in empfängt seine Eingangsdaten vom DSP Plug-in und steht an letzter
Stelle in der Winamp Plug-in Struktur. Es schickt die Daten an das entsprechende
Ausgangsgerät, typischerweise ist dies die Soundkarte. Es gibt aber auch andere
Möglichkeiten, denn Output Plug-ins werden auch dazu benützt, um das von Winamp
verarbeitete Signal wieder auf Festplatte zu schreiben, zum Beispiel als unkomprimierte
wav-Datei oder wieder im mp3-Format. Die Überblendung von einem Titel in den
nächsten Titel kann auch als Output Plug-in realisiert werden.
General Plug-ins haben keinen direkten Einfluss auf das Audiosignal, sie ermöglichen
hingegen einen Zugriff auf Winamp selbst. Es können aktuelle Daten abgerufen und
verarbeitet werden sowie Erweiterungen des Winamp Interfaces realisiert werden.
General Plug-ins laufen ständig im Hintergrund, es können bis zu 256 Plug-ins
gleichzeitig verwendet werden.
Eine wichtige Rolle bei der technischen
Umsetzung von Realisierungsstufe 2 ist die
Möglichkeit mit Winamp ID3 Tags zu
verarbeiten. ID3 Tags können in mp3Dateien enthalten sein und Metadaten über
die
speichern.1
Audiodaten
Realisierungsstufe 2 sieht vor, dass Titel
Abbildung: 3-5 Winamp ID3 Tag
und Interpret auf einer Webseite erscheinen
sollen.
Für
diese
Daten
gibt
es
entsprechende Felder im ID3 Tag, sowie Felder für weitere Informationen.2
Abbildung 3-5 zeigt die MPEG Info Box von Winamp, es sind alle verfügbaren Felder
1. Mehr Informationen zu ID3 Tags ist zu finden bei http://www.id3.org/
2. In Winamp können diese bei laufendem Titel mit „alt + 3“ angezeigt werden.
46
zu erkennen. Für eine Nutzung dieser Daten muss das MPEG Input Plug-in entsprechend
konfiguriert werden.1 Dann können die Daten in der Winamp Playliste angezeigt und
auch von anderen Plug-ins verarbeitet werden. Es gibt inzwischen eine neuere Version
der Tags (ID3v2), die noch weitere Informationen aufnehmen kann (vgl. Abbildung 3-5).
Allerdings sind diese Tags noch nicht so weit verbreitet wie die alte Version, mit dem
Nachteil, dass sie von vielen Plug-ins noch nicht vollständig unterstützt werden, da diese
noch mit der alten C++ ID3 Library programmiert wurden.
Doch wie kommen die Daten in die Tags? Hier gibt es mehrere Lösungen. Am
einfachsten ist es, wenn die Felder direkt bei der Erstellung der mp3-Datei vom
verwendeten Rip-Programm ausgefüllt werden.2 Titeldaten und Interpretendaten für die
jeweilige CD können automatisch aus dem Internet heruntergeladen werden oder von
Hand eingegeben werden. Sie werden dann in die entsprechenden Felder des mp3-Tags
eingetragen. Fehlt bei einem bereits vorhandenen mp3-File das Tag, so kann mit den
meisten Abspielprogrammen das Tag angezeigt und ausgefüllt werden. Dies ist jedoch
relativ zeitaufwendig und deshalb nur bei einer kleinen Anzahl an Dateien praktikabel.
Es gibt einige Tools, die das massenhafte Ausfüllen von mp3-Tags ermöglichen.
Bewährt hat sich im praktischen Einsatz das Programm „ID3 TagIt“.3 Mit Hilfe dieses
Tools konnten die Sendungen und Beiträge aus dem GLF Archiv einheitlich benannt
werden, sowie die Daten in die entsprechenden Felder des Tags geschrieben werden. Als
sehr hilfreich erweist sich auch die Möglichkeit mit „ID3 TagIt“ evtl. vorhandene ID3v2
Tags komplett aus den Dateien zu entfernen, denn wenn beide Tags vorhanden waren
wurden die Informationen – wie Titel und Interpret – auf der Webseite doppelt
dargestellt. Dies ist auf die o.g. mangelnde Unterstützung der neuen Tags
zurückzuführen. Die für Realisierungsstufe 2 benötigten Daten können problemlos in
den Feldern der alten ID3 Version untergebracht werden.
Das Schema in Abbildung 3-6 auf Seite 48 zeigt den Fluss der Audiodaten durch
Winamp und die verwendeten Plug-ins. Im Vergleich mit der Realisierungsstufe 2 sind
1. Siehe Nullsoft, MPEG Input Plug-in, 2001
2. Diese Programme werden auch „CD-Ripper“ genannt und wandeln Audio CDs in ein Datenformat wie
mp3 oder Realaudio um.
3. Siehe auch Kapitel 2.1.3 -„Sonstige Tools“
47
24 kbps-Stream
56 kbps-Stream
An Clients
An Clients
Winamp
+ Playlist
DSPPlug-in 1
erzeugt
24 kbpsStream
Erzeugt
automatische
Überblendungen
DSPPlug-in 2
erzeugt
56 kbpsStream
Advanced
Crossfading
Plug-in
DSP
Stacker
Plug-in
Rock Steady
Audiosignalfluß
Abbildung: 3-6 Schema Realisierungsstufe 2
48
Limiter Plug-in
einige Veränderungen ersichtlich: Als Output Plug-in ist hier das „Advanced
Crossfading“ (ACF) Plug-in installiert.1 Dieses Plug-in realisiert die automatische
Überblendung vom Ende des aktuellen Titels in den Anfang des neuen Titels. Es gibt
mehrere Plug-ins mit denen eine automatische Überblendung umgesetzt werden kann,
jedoch muss dann die Überblendzeit fest angegeben werden. Die Besonderheit des ACF
Moduls ist es hingegen, dass die Überblendzeit durch die Analyse des Audiosignals
dynamisch berechnet wird. Durch eine Vielzahl an Einstellungsmöglichkeiten kann das
Plug-in an die jeweiligen Bedürfnisse angepasst werden. Insbesondere die Parameter für
den Audiopegel, bei dem eine Ein- oder Ausblendung erwünscht wird sowie die
Puffergröße – diese regelt die Vorausschau-Zeit und damit die maximale Überblendzeit –
haben starken Einfluss auf das Ergebnis, welches über Lautsprecher zu beurteilen ist. Es
braucht viel Zeit und Versuche um eine Einstellung zu finden, die sowohl für Musik als
auch für Beiträge verwendbar ist. Besonders bei Wortbeiträgen kann es sein, dass das
ACF Plug-in den letzen Satz abschneidet, wenn dieser nicht einen hohen Audiopegel
aufweist. Ist das Plug-in schließlich eingerichtet, so ergibt sich ein Audiosignal, bei dem
es keine zu leisen Stellen zwischen den einzelnen Titeln gibt. Ist ein Stück am Anfang zu
leise, so wird es erst eingeblendet, wenn genügend Pegel vorhanden ist. Endet ein Stück
mit einer langsamen Ausblendung, so wird das nächste Stück schon früher eingeblendet.
Wortbeiträge und Jingles werden ohne hörbare Lücke in das Signal eingegliedert.
Als Output Plug-in steht das ACF Plug-in an letzter Stelle im Winamp Signalfluss, so
dass das Signal standardmäßig nicht mehr von einem DSP Plug-in verarbeitet werden
kann.2 Um aber die Überblendungen auch im Audiostream hören zu können, muss das
Shoutcast DSP Plug-in das vom ACF Plug-in erzeugte Signal als Eingangsquelle
erhalten. Das ACF Plug-in hat deswegen eine interne DSP Sektion, bei der alle in
Winamp installierten DSP Plug-ins aufgelistet sind; das Shoutcast DSP Plug-in kann
somit das richtige Signal erhalten. Jedoch gilt auch hier die Beschränkung, dass nur ein
einziges Plug-in zur gleichen Zeit verwendet werden kann.
Realisierungsstufe 2 sieht jedoch vor, dass ein Winamp zwei Shoutcast- Streams erzeugt
und das Signal außerdem noch mit einem Dynamik-Effektmodul bearbeitet wird. Damit
1. Download und weitere Informationen unter http://www.sqrsoft.com/
2. Vgl. Abbildung 3-4 auf Seite 45
49
dies realisiert werden kann ist der Einsatz des „DSP Stacker“ Plug-ins notwendig. Der
DSP Stacker ist selbst ein DSP Plug-in, in dem weitere DSP Plug-ins in Reihe geschaltet
werden können.1
Wie in Abbildung 3-6 auf Seite 48 ersichtlich, sind im DSP Stacker Plug-in drei weitere
DSP Plug-ins eingerichtet. An erster Stelle steht „Rock Steady“, ein Modul das zur
Dynamikkompression und als Limiter eingesetzt ist und nach einigen Tests mit anderen,
ähnlichen Plug-ins sich als am besten klingende Lösung erwiesen hat. Das Signal mit
dem so maximierten Audiopegel wird nun an die beiden Shoutcast DSP Plug-ins
weitergleitet.
Das Shoutcast DSP Plug-in 2 erzeugt den 24 kbps Stream und ist genau gleich
konfiguriert wie das DSP Plug-in von Winamp 2 in Realisierungsstufe 1. Das 56 kbps
Plug-in hingegen ist anders konfiguriert, da es keinen Loopback Server mehr gibt. Der
ehemalige Shoutcast Relay Server von Realisierungsstufe 1 ist jetzt als normaler
Shoutcast-Server konfiguriert, so dass das Shoutcast DSP Plug-in 1 seinen 56 kbps
Stream nun direkt an diesen senden kann. Für die Hörer von Radio GLF hat sich somit
nichts geändert, sie haben weiterhin die Auswahl zwischen einem 24 kbps Stream und
einem 56 kbps Stream, die von den gleichen Servern wie in Realisierungsstufe 1
gesendet werden.
Eine weitere Vorgabe, die in dieser Stufe umzusetzen ist sind die Zusatzinformationen,
die auf der Webseite angezeigt werden sollen. Es gibt für Winamp einige Plug-ins, die
für eine automatische Generierung von Dateien geeignet sind. Da es sich dabei um
Aufgaben handelt, die nicht direkt den Audiostream beeinflussen und im Hintergrund
ablaufen können, handelt es sich hierbei um Plug-ins vom Typ „General“.2 Zwei davon
eignen sich besonders zum Erzeugen von HTML Seiten: DoSomething - „Whenever a
song changes ... this plugin is responsible for doing ‚something’“3- und MusicTicker4.
Letzteres wird jedoch anscheinend nicht mehr weiter entwickelt.5 DoSomething wird zur
1.
2.
3.
4.
50
Download und weitere Informationen unter http://www.spacialaudio.com/
vgl. Abbildung 3-4 auf Seite 45
Download und Dokumentation unter http://www.oddsock.org/tools/dosomething/
Download und Dokumentation unter http://www2.kenyon.edu/People/varmaa/mticker/
Zeit noch ständig weiterentwickelt und in der Funktionalität erweitert, weshalb dieses
Plug-in in Realisierungsstufe 2 zum Einsatz kommt.
Input-Templates
Parsed Templates und
ersetzt Variable mit
echten Daten
Do Something
Plug-in
Übertragung der HTML
Seiten per FTP auf
Webserver
Webserver
Fertige HTML Seiten
Abbildung: 3-7 Realisierungsstufe 2 - Schema DoSomething
5. Im Allgemeinen werden die meisten Plug-Ins für Winamp von Privatpersonen in deren Freizeit
programmiert und bei http://www.winamp.com/plugins/ kostenlos zum Download angeboten. Es gibt
deshalb große Unterschiede in der Qualität der Plug-ins, die von „unbrauchbar“ bis „professionell“
reicht.
51
DoSomething verwendet Daten, die von Winamp aus der Playlist, dem ID3 Tag der
jeweiligen Titel stammen, sowie Daten, die es via XML vom Shoutcast-Server bekommt
- sollte einer in Betrieb sein. Die so gewonnenen Informationen werden intern in
Variablen gespeichert. Es können nun Templates angelegt werden, also typischerweise
ein HTML oder Textdatei, bei denen dann von DoSomething Platzhalter-Tags, wie
beispielsweise %%CURRENTSONG%% für den aktuellen Titel, durch die aktuellen Werte der
entsprechenden Variable ersetzt werden. Die so erzeugte Datei wird dann anschließend
per FTP von DoSomething auf einen Webserver übertragen. In Abbildung 3-7 ist der
grundsätzliche Ablauf skizziert. Oben sind die Input-Templates dargestellt, man kann
dort die einzelnen Platzhalter-Tags erkennen. Wenn in Winamp nun ein Titelwechsel
stattfindet werden diese Templates von DoSomething verarbeitet und in die unten
dargestellten fertigen HTML Seiten gewandelt; es sind die Platzhalter mit den
entsprechenden aktuellen Informationen zu erkennen. Anschließend lädt das Plug-in die
Seiten per FTP auf den GLF Webserver, und die Besucher der Webseite werden mit den
aktuellen Informationen zum Programm versorgt.
Es ist zu beachten, dass die Informationen nur zu dem Zeitpunkt aktuell sind, zu dem der
Besucher die Webseite aufruft. Die Informationen auf der „jetzt läuft“ und der „Playlist“
Seite veralten, sobald ein neuer Titel gespielt wird. Da es sich bei diesen Seiten um
normale Webseiten handelt, eignet sich zum Pushen der Informationen ein
„automatisiertes Pull“ Verfahren. Bei diesem Verfahren aktualisiert der Webbrowser die
HTML-Seite nach einer bestimmten Zeit, die im Quellcode der Seite angegeben ist. Hat
die Seite auf dem Webserver ein neueres Erstellungsdatum als die Seite, die im Moment
dargestellt wird, so lädt der Browser die Seite herunter. Ist das Erstellungsdatum gleich,
so zeigt er die Seite aus dem lokalen Cache Speicher an. Zu beachten ist, dass selbst
wenn die Seite nicht heruntergeladen wird dennoch eine Verbindung zum Server
aufgebaut werden muss, um zu überprüfen, ob es eine neuere Version der Seite gibt.
Dieser Verbindungsaufbau erfordert – zwar nur sehr wenig – Bandbreite, die den anderen
Diensten der Seite dann fehlt. Bei Webcasting Angeboten ist die verfügbare Bandbreite
meist bis an die Grenze ausgelastet, so dass überflüssige Belastungen zu vermeiden sind.
Auf dieser Basis sind dann Überlegungen zur „Refresh“ Zeit der beiden HTML Seiten zu
machen.
52
Es geht nicht nur darum, unnötige Datenübertragungen zu vermeiden, denn jede
Aktualisierung erfordert auch Systemressourcen, die je nach verwendetem System mehr
oder weniger begrenzt sind. Einige Test auf verschiedenen Systemen haben
erwartungsgemäß zu unterschiedlichen Wirkungen geführt. Im günstigsten Fall
beeinträchtigt ein „Refresh“ die Webcasting- Darbietung überhaupt nicht. Nur unschön
ist ein Flackern der Seite, das entsteht, wenn die Seite nicht vom Server sondern aus dem
Cache nachgeladen wird. Wenn die Seite vom Server geladen wird, hat sie einen anderen
Inhalt, so dass ein Flackern als nicht störend empfunden wird. Im schlimmsten Fall kann
eine Aktualisierung der Seite im Abbruch des Audiostreams resultieren.
Diese Nebenwirkungen sprechen für eine relativ lange „Refresh“ Zeit, die so gut wie
möglich mit der Dauer eines Titels übereinstimmen sollte, den erst nach einem
Titelwechsel sind neue Informationen verfügbar. Mit DoSomething ist es möglich, die
Titeldauer in Sekunden über ein weiteres Platzhalter-Tag im Template in das
entsprechende Meta-Tag der fertigen HTML-Seite zu schreiben, so dass die
Aktualisierung zum richtigen Zeitpunkt stattfindet. In einer ersten Version wurde dies
dann entsprechend umgesetzt. Bei einem typischen GLF Sendungsmitschnitt, der aus
dem Archiv gesendet wird, würde eine Aktualisierung der Seite nach 120 Minuten
stattfinden. In unserem Fall ist das Problem dabei, dass der Browser mit dem Countdown
der Zeit erst anfangen kann, wenn er die Seite geladen hat. Kommt nun ein Hörer erst
gegen Ende der 120 Minuten Sendung auf die Seite, so würde eine Aktualisierung
ebenfalls erst nach 120 Minuten erfolgen, selbst wenn in der Zwischenzeit schon einige
andere Titel gespielt wurden. Der Hörer könnte dann zwar von sich aus die Seite
nachladen - das Ziel, stets den aktuellen Titel automatisch auf der Webseite anzuzeigen,
ist damit jedoch nicht erreicht. Ein Fehler im DoSomething Plug-in führt außerdem dazu,
dass die Aktualisierungszeit auf 0 Sekunden eingestellt wird, wenn der Sende-Winamp
geschlossen wird. Die resultierende pausenlose Aktualisierung der Seite kann meist nur
mit dem Taskmanager beendet werden.
In einer zweiten Version ist deshalb die „Refresh“ Zeit fest eingetragen und für alle Titel
gleich. Bei der „jetzt läuft“ Seite beträgt diese 25 Sekunden, bei der „Playlist“ Seite 60
Sekunden. Diese Zeiten haben sich bei einigen Tests als guten Kompromiss erwiesen.
Die kürzesten Audioclips, die bei Radio GLF gespielt werden, sind Jingles mit einer
53
Dauer von meist unter 10 Sekunden, gefolgt von MI2 Audiospots mit ca. 60 Sekunden.
Die Titel der Jingles müssen nicht auf der Webseite angezeigt werden, und mit einer
„Refresh“ Zeit von 25 Sekunden werden gemäß dem Abtasttheorem1 alle Titel mit mehr
als 50 Sekunden Spieldauer zuverlässig angezeigt.
Die „Playlist“ Seite hat mit 60 Sekunden eine längere „Refresh“ Zeit, da die
Informationen nur für den Gebrauch im Hintergrund konzipiert und deshalb in einem
extra Fenster untergebracht sind. Die Seite wird bei Bedarf aufgerufen und zeigt dann die
aktuellen Informationen an. Sehr kurze Titel werden dennoch angezeigt, da sie auf der
„die letzten 10“ Liste nach unten wandern.
Das DoSomething Plug-in besitzt noch weitere Funktionen, die aber für die Umsetzung
der Stufe 2 nicht benötigt werden.
3.2.2.3Praktischer Einsatz Realisierungsstufe 2
In der Praxis ist das System der
Realisierungsstufe 2 einfacher zu
Starten
als
das
der
Stufe
1.
Vorausgesetzt, die beiden ShoutcastServer
auf
dem
Linux-Rechner
(glfservice) sind betriebsbereit, so
muss lediglich Winamp gestartet und
in
den
werden.
Abspielmodus
Anschließend
versetzt
sind
Abbildung: 3-8 Realisierungsstufe 2 in Betrieb
die
beiden Shoutcast DSP Plug-ins zu konnektieren. In aller Regel funktioniert dies ohne
Probleme, so dass wiederum zwei Streams mit 24 kbps und 56 kbps erzeugt werden und
des weiteren die Webseite mit textuellen Informationen zum Audiostream versorgt wird.
Abbildung 3-8 zeigt die Anordnung von Winamp und Plug-ins, wie sie in
Realisierungsstufe 2 auf dem Desktop erscheinen.
1. Das Abtast- oder Nyquist-Theorem wird normalerweise bei der Digitalisierung von analogen Signalen
beachtet, vgl. auch Steinmetz, Multimedia-Technologie, 1999, S. 98: „Zur Festlegung der
Abtastfrequenz muß das Nyquist-Theorem beachtet werden, nach dem das abzutastende Signal keine
Frequenzkomponenten enthalten darf, die größer als die Hälfte der Abtastfrequenz sind.“
54
Das System zu starten ist demzufolge ziemlich einfach möglich. Es sind jedoch
umfangreiche Vorbereitungen und Konfigurationen nötig, um dies zu erreichen. Das
Advanced Crossfading Plug-in ist mit der Version 1.60 eingesetzt, diese Version enthält
ein paar Fehler, die das Plug-in und somit auch Winamp zum Absturz bringen. Die
Funktion „Do not crossfade tracks smaller than” ist überhaupt nicht funktionstüchtig,
würde aber benötigt werden, damit Jingles und kurze Beiträge nicht abgeschnitten
werden. Alternativ lässt sich auch die Puffergröße verkleinern, so dass es nur eine sehr
kurze Überblendzeit gibt, die dann nur einen kaum bemerkbares Abschneiden zur Folge
hat.
Die Konfiguration von DoSomething erfolgt gemäß der dazugehörigen Dokumentation.1
Zu beachten ist, dass nur absolute Pfadangaben zu den Templates funktionieren. Dies ist
etwas mehr Schreibarbeit und ansonsten nur von Bedeutung, wenn das System in ein
anderes Verzeichnis oder auf einen anderen Rechner kopiert wird. Außerdem sollten
Statusmeldungen und Fehlermeldungen nicht aktiviert sein. Die Funktion des Plug-ins
wird zwar durch eine Aktivierung nicht beeinträchtigt, es kann nur sein, dass sich
manche Statusfenster nicht mehr von selbst schließen, so dass der Desktop mit diesen
Fenstern unnötig belegt wird.
Das Limiter Plug-in „Rock Steady“ ist sehr einfach zu konfigurieren, da es
Voreinstellungen unterstützt. Die Einstellung „Soft Compression“ führt zu guten
Ergebnissen, letztendlich ist es aber eine Frage des persönlichen Geschmacks, wie „laut“
Radio GLF klingen soll.
Ist das System gut konfiguriert so verläuft der praktische Einsatz zufriedenstellend, da
beim automatisierten Betrieb alle Ziele der Realisierungsstufe 2 erreicht werden.
Während
den
Live-Sendungen
gibt
es
jedoch
Schwierigkeiten,
die
programmbegleitenden Informationen weiterhin, ohne erkennbaren Unterschied, in die
Webseite zu integrieren. Im Live-Betrieb werden die einzelnen Titel und Beiträge von
Hand abgefahren, teilweise wird dabei Musik analog über das Mischpult von der CD
oder Vinyl-Platte eingespielt. Die Moderationen erfolgen live aus der Sprecherkabine,
die Dauer einer Moderation ist nur grob vorbestimmt. Es gibt zwei Konzepte, die
1. Siehe Oddsock.org, DoSomething, 2001
55
während des Sommersemesters 2001 getestet wurden, mit denen eine dem
automatisierten Betrieb vergleichbare Aktualisierung der Seiten vorgenommen werden
kann.
Das erste Konzept beruht auf einem PHP Skript, das per Knopfdruck im Webbrowser die
„jetzt läuft“ und die „Playlist“ Seiten aktualisiert. Das Skript befindet sich im selben
Verzeichnis auf dem Webserver wie die zu aktualisierenden Seiten. Außerdem muss es
noch eine Datei namens „playlist.pls“ geben, welche die Titelreihenfolge im Winamp
pls-Format enthält. Um eine korrekte Funktion sicherzustellen, muss der Sendeplan und
die zu spielenden Titel im voraus bekannt sein, damit eine entsprechende Playlist erstellt
werden kann. Werden nun Titel von Vinyl oder CD gespielt und sollen die Moderationen
auch auf der Webseite aufgeführt werden, so muss die pls-Datei – im Grunde eine
Textdatei – von Hand bearbeitet werden. Denn Titel, die nicht im mp3-Format in der
Winamp-Playlist vorliegen werden auch nicht in der pls-Playliste abgespeichert.
Da die Informationen aus den ID3-Tags verarbeitet werden, wird nur eine korrekte Liste
erstellt, wenn für jede Datei ein ausgefülltes ID3-Tag vorhanden ist. Liegt zum Beispiel
ein Beitrag im wav-Format vor, so fehlen die Informationen zu Titel und Autor. Als
Alternative zur (Nach-)Bearbeitung der „playlist.pls“ Datei gibt es die Möglichkeit kurze
mp3-Dateien zu erstellen. Diese sollten nur Stille enthalten und ein entsprechend
ausgefülltes ID3-Tag besitzen. Diese „leeren“ mp3-Dateien können dann in die WinampPlaylist aufgenommen werden und somit auch eine gültige pls-Playliste erstellt werden.
Anschließend wird die Datei per FTP ins entsprechende Verzeichnis auf dem Webserver
geladen. Der jeweilige Verantwortliche muss dann bei jedem neuen Titel die
Aktualisierung der HTML Seiten per Buttonklick veranlassen.
Das zweite Konzept ist im Prinzip identisch mit der automatisierten Lösung. Dazu muss
auf dem Senderechner im Tonstudio ein entsprechend konfigurierter Winamp mit
DoSomething Plug-in und optionalem Advanced Crossfading Plug-in installiert sein. Bei
diesem Konzept kommt man um die Erstellung von leeren, bzw. stillen mp3-Dateien
nicht herum, wenn auch analog eingespielte Quellen – wie Moderationen, Vinyl-Platten
– auf der Webseite erscheinen sollen. Ansonsten ist diese Lösung flexibler als die PHPSkript Lösung, da Titel dynamisch in der Playliste angeordnet werden können.
56
Die Bedienung erfordert dagegen einiges an Übung. Zum einen führt DoSomething seine
Aktionen nur aus, wenn der Titel mit dem „Play“ oder „Next track“ Button abgespielt
werden oder beim Wechsel von einem ausgespielten zum neuen Titel. Bei Abspielen der
Titel durch Doppelklick auf den Eintrag in der Playliste werden keine Aktualisierungen
vorgenommen. Zum andern ist der Umgang mit dem Crossfading Plug-in
gewöhnungsbedürftig. Durch die Zwischenspeicherung des Audiosignals kommt es zu
Verzögerungen, wenn zum Beispiel die „Stop“ oder „Next track“ Buttons gedrückt
werden. Auch ist die Restspieldauer-Anzeige in Winamp durch die Pufferung ebenfalls
nicht mehr gültig, denn sie ist dem Audiosignal am Ausgang von Winamp um die Zeit
der Pufferung voraus.
Insgesamt stellt die Realisierungsstufe 2 im praktischen Einsatz eine zufriedenstellende
Lösung dar. Im automatisierten Betrieb können damit der Klang einer professionellen
Radiostation erreicht werden; das stets aktuelle Angebot auf der Webseite an
Informationen zu den gespielten Titeln erreicht ebenfalls einen professionellen Standard
und übertrifft sogar die Websites mancher kommerzieller Radiosender. Schwierigkeiten,
aktuelle Titelinformationen bei analogen oder noch nicht erfassten Zuspielmedien auf
die Webseite zu übermitteln, gibt es auch bei großen kommerziellen Radiostationen.1
3.2.2.4Probleme
In diesem Kapitel wird näher auf Probleme eingegangen, die sich bei der praktischen
Umsetzung der Realisierungsstufe 2 gezeigt haben.
Als kritisch erweist sich die Refresh-Rate der HTML-Seiten. Wie bereits erwähnt ist
dabei zu beachten, dass ein Refresh zusätzliche Bandbreite beansprucht und ein zu
häufiger Refresh den Audiostream zum Abbrechen bringen kann. Lange Refresh-Zeiten
bedeuten, dass die Seite möglicherweise zu alt ist und nicht die aktuellen Daten des
Audiostreams darstellen. Ein weiteres Problem ist, dass es zu immer unterschiedlichen
Verzögerungen kommt, nach denen ein Hörer sein Audiosignal aus dem Abspieler
anhören kann. Es gibt eine Reihe Faktoren, die Einfluss auf die Verzögerung haben, wie
1. Wie in einem Informationsgespräch mit Oliver Reuther, SWR3 online, Baden-Baden am 30.5.2001 zu
erfahren war.
57
zum Beispiel die Puffergröße, Leitungsqualität, die maximal zur Verfügung stehende
Bandbreite des Hörers. Aber auch die Ausstattung und Auslastung des Servers haben
Einfluss auf die Verzögerung. Diese Faktoren können von der Serverseite kaum
zuverlässig und individuell abgeschätzt werden.
Ein Hörer hat beispielsweise eine 46 kbps Modemverbindung ins Internet, damit möchte
er den 24 kbps mp3-Stream anhören. Der Puffer in Winamp ist auf 10 Sekunden
eingestellt. Im Idealfall beträgt also die Zeit, um den Puffer zu füllen ca. 5 Sekunden; in
der Realität ist mit einer längeren Zeit zu rechnen, da normalerweise der Stream nur
nebenher, also neben dem Surfen im Internet, konsumiert wird. So kommt es schon hier
zu einer Verzögerung von fünf bis zehn Sekunden, bis das Audiosignal den Hörer
erreicht.
Zusätzlich kann es zu Verzögerungen von der Serverseite aus kommen. Eigene Tests im
Studio LAN des Fachbereichs Digitale Medien haben gezeigt, dass es bis zu zwei
Minuten Verzögerung vom Abspielen des Titels bis zum Empfang des Titels in Winamp
geben kann. Diese Zeit ist anscheinend abhängig von der (Hauptspeicher-) Auslastung
des Servers. Jeder Winamp Client benötigt einen gewissen Anteil an Hauptspeicher auf
dem Server. Je mehr Clients auf einen Server verbinden, desto kürzer werden die
Verzögerungen. Gibt es nur einen Client, so füllt der Server den gesamten internen
Puffer mit dem Stream, so dass der Client am Anfang schon ältere Datenpakete erhält.
Die Verzögerungen sind also bei jedem Client unterschiedlich lang. Das heißt, dass nicht
vorhergesagt werden kann, wann ein bestimmter Titel bei einem Hörer ankommt. Im
Gegensatz zum Stream gibt es bei den Webseiten nur sehr geringe Verzögerungen, mit
dem Effekt, dass zum Beispiel die „jetzt läuft“ Seite einen Titel anzeigt, den der Hörer
erst in einer Minuten zu hören bekommt. Unter diesem Gesichtspunkt sind die RefreshZeiten der Seiten mit 25 bzw. 60 Sekunden als genau genug einzuordnen. Eine auf die
Sekunde genaue Synchronisation wird mit diesem System jedoch nicht möglich sein.
Das Problem der Synchronisation von Audioinformationen mit begleitenden
Textinformationen ist im Multimedia-Bereich nichts Neues. Im Radiobereich war im
Rahmen von DAB ein ähnliches Problem zu lösen, die programmbegleitenden Daten
(PAD), also Bilder und Texte, sollen hier synchron zum Audiosignal in einem zum DAB
Empfänger
58
gehörenden
Monitor
angezeigt
werden.
Dabei
„...
sind
die
programmbegleitenden Daten in den Audiodatenstrom eingebettet [...]. Jedes Datenpaket
im Audiostrom trägt quasi huckepack ein PAD-Zusatzdatenpaket, wodurch eine klare
Korrelation der beiden Datenströme gewährleistet ist.“1 Ähnliche Verfahren werden
auch bei Real und Microsoft eingesetzt. Es können in Echtzeit Befehle in den
Audiostream eingebettet werden, die dann den Refresh der HTML Seiten veranlassen.
Die Befehle sind mit dem Audiosignal fest verbunden, was bedeutet, dass sie zu der Zeit
beim Nutzer ankommen, zu der auch das entsprechende Audiosignal ankommt. Eine
Synchronität der Daten ist also gewährleistet. Bei Real wird dies mit SMIL realisiert, die
Befehle werden vom Encoder live in den Stream eingebettet. Bei Microsoft gibt es die
Möglichkeit ebenfalls mit dem Encoder „Script Commands“ in den Datenstrom
einzubetten.
Leider handelt es sich hierbei immer um proprietäre Lösungen, es gibt kein
standardisiertes Interface, dem ein entsprechender Befehl übergeben wird und das
Interface die Weiterleitung an den jeweiligen Encoder übernimmt. Die Forderung nach
Plattformunabhängigkeit kann mit einer solchen Lösung also nicht entsprochen werden,
denn für eine Automatisierung der Scriptbefehle müsste jeweils für Microsoft und für
Real ein spezieller Encoder programmiert werden, der eine Anbindung an das Ausspiel
System ermöglicht. Bei Audiostreams im mp3-Format wird es nochmals komplizierter.
Eine Einbettung von Befehlen in den Stream ist auch hier möglich, allerdings müsste
nicht nur ein Interface für den Encoder (das Shoutcast DSP Plug-in) programmiert
werden, sondern auch ein Plug-in für den Abspieler, der dann den Befehl an den
richtigen Frame im Browser weiterleitet.
Zum Thema Synchronisation bleibt abschließend die Frage, ob die erreichte
Synchronisation überhaupt noch als synchron zu bezeichnen ist. Denn „Was als
synchronisiert gelten soll, ist medien- und inhaltsabhängig. Bedingungen müssen für
tolerierbare Zeitintervalle des angestrebten Optimums formulierbar sein“.2 Das
Optimum wäre, wenn die Anzeige des Titels und Interpreten eines Musikstücks
zeitsynchron mit dem Anfang des Stücks geschehen würde. Tolerierbar jedoch sind
Abweichungen, die den Nutzwert der Textinformationen nicht vollständig vernichten.
1. Andreas Wessendorf in: Lauterbach, DAB, 1996, S. 131
2. Steinmetz, Multimedia-Technologie, 1999, S. 578
59
Da bei Radio GLF das Programm meist aus Titeln besteht, die länger als eine Minute
sind, oft aber auch länger als eine Stunde (wie dies bei Sendungsmittschnitten der Fall
ist), können Abweichungen von einer Minute gerade noch toleriert werden.
Die Testläufe haben gezeigt, dass diese Toleranzgrenze vom System erfüllt wird (wenn
es funktioniert) und von den Nutzern als nicht störend empfunden wird.
Als großes Problem erwies sich der Einsatz des Advanced Crossfading (ACF) Plug-ins.
Das Plug-in hat noch einige interne Programmierfehler, so dass ein längerer stabil
laufender Einsatz ohne Beaufsichtigung kaum möglich ist. Besonders bei der
Verschachtelung von Plug-ins, wenn also in das ACF Modul weiter Plug-ins geladen
werden, waren häufig Abstürze zu beobachten. Weiterhin war zu beobachten, dass bei
sehr kurzen Titeln von unter zehn Sekunden es oft zu Hängern kam, bei denen der kurze
Titel mehrmals hintereinander oder schlimmstenfalls in einer Endlosschleife gespielt
wurde. Auch bei sehr sorgfältiger Justierung kam es bei manchen Wortbeiträgen vor,
dass das Ende des Beitrags frühzeitig vom Plug-in ausgeblendet und der nächste Titel
abgefahren wurde. Hinzu kommen noch die im vorigen Kapitel erwähnten
Schwierigkeiten beim Live-Einsatz des Plug-ins. Insgesamt überwiegen im Moment
noch die Probleme beim Einsatz dieses Moduls, so dass nach einigen Wochen Probezeit
auf den Einsatz des Plug-ins verzichtet wurde. Es ist jedoch mit jeder neuen Version des
Moduls eine deutliche Qualitätssteigerung spürbar, es ist folglich denkbar, dass in einiger
Zeit ein Einsatz denkbar ist.
Die im vorigen Kapitel geschilderten Probleme, während Live-Sendungen die
Aktualisierung der „Playlist“ Seite und der „jetzt läuft“ Seite zu realisieren, können mit
denen
dort
vorgestellten
Konzepten
gelöst
werden,
allerdings
nicht
voll
zufriedenstellend. Die Praxis hat gezeigt, dass die Bedienung des Winamps mit
DoSomething Plug-in oder die Verwendung des PHP-Skripts sowohl Konzentration wie
auch Übung erfordert. Dies ist während hektischer Live-Sendungen nicht immer
gewährleistet. Eine bequemere und einfachere Lösung ist im Moment nicht realisierbar.
Durch genauere Planung und einen geregelteren Ablauf der Sendung, sowie einer
besseren Schulung der Musikverantwortlichen kann jedoch eine korrekte Aktualisierung
der Webseiten erleichtert werden.
60
3.2.3.1Wünsch’ dir’s mit SAM
„Streamies are highly interactive and involved with the internet.”1
In Realisierungsstufe 2 sind bereits alle grundlegenden Funktionalitäten eines
Webcasting-Systems in die Praxis umgesetzt. Die Nutzer erhalten Informationen über
den aktuell gespielten Titel und können sich bei Bedarf über die zuletzt gespielten Titel
informieren.
Webcasting-Nutzer
gehören
allerdings
zu
einer
Gruppe
von
Internetanwendern, die im Netz sehr aktiv sind, Möglichkeiten der Interaktion
überdurchschnittlich annehmen und sehr weit in die Tiefe des Internets vordringen.2
Dieser Gruppe wird das Konzept der Stufe 2 nicht ganz gerecht, da nur sehr wenig
(Inter)Aktivität von Nutzerseite möglich ist und es kein Angebot an tiefergehenden
Informationen über den aktuellen Audiostream gibt.
Ziel der Realisierungsstufe 3 ist es, die Möglichkeiten und Angebote auszubauen, die der
Besucher der Radio GLF Webseite nutzen kann und damit die Attraktivität der Webseite
weiter zu steigern. Mehr Information und mehr Interaktion sind für die Erreichung des
Ziels notwendig.
Ein größeres Angebot an Informationen über den gerade zu empfangenden Audiostream
stellt einen Anreiz dar, die Seite weiter zu nutzen. Denn das Suchen von Informationen
ist die am zweithäufigsten genutzte Anwendung im Internet.3 Folglich können mit
Zusatzinformationen, die frei Haus geliefert werden, eine Breite Masse an Nutzern
angesprochen werden. Idealerweise sollten diese intern, auf der eigenen Webseite
vorhandenen Informationen, durch Hinweise oder Links auf weitere externe
Informationen unterstützt werden. Konkret sollen in der Realisierungsstufe 3 in Bezug
auf das Informationsangebot einige der in Kapitel 2.3 vorgestellten Konzepte umgesetzt
werden. Die in der Realisierungsstufe 2 umgesetzten Angebote bleiben bestehen, werden
aber durch eine HTML Seite erweitert, die folgende Inhalte anbietet:
•
Name des aktuellen Titels
1. Arbitron, Internet V, 2000, S. 2
2. Vgl. Arbitron, Internet VI, 2001, S. 30 ff.
3. Diese Erkenntnis wird immer wieder durch verschiedene Studien bestätigt. Siehe auch Arbitron, ECommerce, 1999, S. 18 und Feierabend/Klingler, JIM, 2000, S. 41 f.
61
•
Aktueller Interpret
•
Name das Albums, auf dem der Titel zu finden ist
•
Erscheinungsjahr des Titels
•
Ein Feld mit Zusatzinformationen, das zum Beispiel für Rezensionen, Tourdaten,
Informationen zum Interpreten oder weitere Trivia genutzt werden kann.
•
Wenn vorhanden, wird ein Bild des Albumcovers oder des Interpreten gezeigt.
Die Informationen, die auf dieser Seite angezeigt werden, sind immer noch
oberflächlich, deshalb gibt es einen Button oder Link, mit dem sich eine externe
Datenbank abfragen lässt. Je nachdem, welchen Link der Besucher klickt wird eine
Abfrage der externen Datenbank nach Titel, Interpret oder Album durchgeführt und die
Ergebnisse in einem neuen Browserfenster angezeigt. In einer kommerziellen
Umgebung kann die externe Datenbank das Angebot eines Online-Shops wie zum
Beispiel Amazon.de oder cdnow.com enthalten und der Hörer kann den Titel, den er
gerade hört gleich kaufen. Zu vielen Titeln gibt es zusätzlich Kritiken, weitere
Informationen und Meinungen von Käufern. Kauft der Hörer tatsächlich etwas,
bekommt der Sender eine Provision. Da jedoch im Rahmen dieser Arbeit keine
kommerziellen Aspekte beachtet werden, sollte mit den o.g. Links eine Datenbank
abgefragt werden, bei der nicht das Verkaufen des Titels im Vordergrund steht, sondern
die Informationen über und rund um den Titel, wie zum Beispiel Chartpositionen,
Coverversionen, Liedtexte, beteiligte Personen, etc.
Weiterhin soll in Stufe 3 mehr Interaktion für den Nutzer möglich sein. Doch welche
Interaktion ist sinnvoll, bezieht den Hörer mehr in die Sendung ein und kann vor allem
auch mit vertretbarem Aufwand automatisiert werden?
62
Sehr
begehrt
sind
konventionellen
im
Radio
Sendungen
wie
Hörerhitparaden
oder
Sendungen, bei denen der
Hörer
sich
ein
Titel
wünschen kann. Kann der
Hörer
Musikwünsche
äußern, die anschließend
auch gespielt werden, so hat
eine Interaktion mit dem
Quelle: Arbitron, 1998, The Arbitron Internet Listening Study, S. 14
Abbildung: 3-9 Hörerzufriedenheit
Sender stattgefunden, die
den Hörer direkt in den
Sendeablauf
einbezogen
hat. Viele Hörer sind mit dem Musikprogramm eines Radiosenders nicht zufrieden, wie
in Abbildung 3-9 zu erkennen ist.
Im Internet kann diesen Hörern eine Möglichkeit gegeben werden, ihre Wünsche auf
sehr einfache und bequeme Weise zu erfüllen. Gleichzeitig erfährt der Sender so auch
etwas über seine Hörer. Das Wünschen von Titeln stellt also für beide Seiten eine
lohnenswerte Interaktion dar. Diese Funktion lässt sich technisch wie redaktionell mit
nicht zu großem Aufwand umsetzen. Auf die technische Umsetzung wird im nächsten
Kapitel eingegangen, deshalb an dieser nur einige Überlegungen zum redaktionellen
Konzept.
Zunächst ist festzulegen, wann und wie der Hörer seinen Wunsch bekannt gibt. Da es
sich bei Webcasting, ähnlich wie bei konventionellem Radio, meist um ein öffentliches
Medium handelt, liegt es nicht im Interesse des Betreibers, seinen Sender als Plattform
für extremistische Gruppen zur Verfügung zu stellen, die dann durch die Wünsche ein
Programm zusammenstellen können, das nur sehr wenige anspricht und die Mehrheit der
63
Hörer zum Abschalten anregt.1 Eine Wunschfunktion muss also auf eine gewisse Weise
redaktionell betreut werden.
Eine Musikredaktion sammelt und bewertet die Hörerwünsche und sucht dann einige
aus, die gesendet werden. Dieses Vorgehen kann eigentlich nicht automatisiert werden.2
Deshalb ist ein Freiform-Feld, in den der Hörer seinen Wunsch eintippen kann, nicht
sinnvoll. Vielmehr sollte dem Hörer eine Liste präsentiert werden, die alle spielbaren
Titel enthält und die ohne Bedenken gespielt werden können. Durch ein zeitliches
Rotieren der Wunschlisten kann außerdem Einfluss auf die Wünsche genommen werden.
Gibt es zum Beispiel einen Hip-Hop Themenabend, so können nur Listen mit
entsprechenden Titeln veröffentlicht werden. Da es bei Radio GLF derzeit noch keine
spezielle (Themen-) Sendungen gibt, die automatisiert ablaufen könnten, wird jedoch auf
diese Option verzichtet. Es sind deshalb Wunschlisten vorgesehen, die alle im Archiv
verfügbaren Musiktitel, Beiträge und Sendungsmitschnitte enthalten. Zusätzlich muss
sichergestellt sein, dass nicht ein einzelner zuviel Einfluss auf das Programm hat, was
bedeutet, dass er nicht unbegrenzt Wünsche in einem gewissen Zeitrahmen loswerden
kann. Es gibt in verschiedenen Ländern verschiedene Regelungen und Gesetzte, die
regeln, wie viele Wünsche in welcher Zeit gespielt werden dürfen.3 Zeitnahes Senden
der Wünsche ist mit Audio on-demand vergleichbar; für diese Dienstleistung bestehen
andere gesetzliche Regelungen als für eine Rundfunksendung. Rechtliche Aspekte
werden im Rahmen dieser Arbeit nicht behandelt, so dass diese bei der Konzeption auch
nicht beachtet werden.
Ferner ist es ein Ziel der Realisierungsstufe 3 ein Sendeformat zu entwickeln, um dies
automatisiert umsetzen zu können. Es soll demonstriert werden, dass ein zeitgenaues
Rotieren von Playlisten möglich ist, wobei ferner in einem festgelegten Rhythmus
automatisch Werbespots, Jingles und Station IDs eingefügt werden. Zum Zeitpunkt der
Konzeption von Realisierungsstufe 3 gibt es jedoch noch keine Statistiken oder
Umfragen, aus denen Details über die Wünsche und Vorlieben der Radio GLF Hörer
1. Zu Beispiel, wenn auf einem Mainstream Sender einige Titel Hardcore Punk oder DJ Bobo aufeinander
folgen.
2. In Zukunft wäre dies durch künstliche Intelligenz durchaus denkbar.
3. Die USA sind hier mit dem „Digital Millenium Copyright Act“ (DMCA) von 1998 in der VorreiterRolle.
64
entnommen werden können. Das entwickelte Format dient deswegen nur zu
Demonstrationszwecken und umfasst nur einen Tag, d.h. es wird jeden Tag nach
demselben Schema gesendet. Die meiste Zeit über wird Musik gesendet, die aus einer
speziell zusammengestellten Playlist zufällig ausgewählt wird. Das Motto dieser Liste
könnte zum Beispiel „Album of the Day“ oder „Special of the Week“ sein. Die Titelfolge
wird nach jeweils drei gespielten Titeln durch ein Jingle unterbrochen, zu jeder halben
Stunde erfolgt eine Werbeunterbrechung. Während dieser Zeit ist die Wunschfunktion
aktiviert, die gewünschten Titel werden sofort in die Queuelist aufgenommen und
gespielt. Ab 22:00 Uhr wird dieser Rhythmus unterbrochen, es folgt eine neue Playliste,
die diesmal eine komplette Sendung in einzelnen Dateien enthält, das Motto der Liste
könnte zum Beispiel „Feature“ oder „Magazin“ heißen, es wechseln sich Beiträge,
Musik und Moderationen ab. Die Wunschfunktion ist deaktiviert, Wünsche werden
gesammelt und nach Beendigung der Sendung gespielt. Sollte das Feature nicht bis
23:00 Uhr dauern, wird die restliche Zeit mit zufälligen Titeln aus dem Archiv aufgefüllt.
Ab 23:00 Uhr wird ein zufällig ausgewähltes Hörspiel aus dem Archiv gesendet, danach
Werbung und anschließend fängt das Schema wieder von vorne an.
Zuletzt ist es ein Ziel von Realisierungsstufe 3 den Stream zusätzlich in einem anderen
Format als mp3 anzubieten, d.h. es soll entweder noch einen Microsoft asf-Stream geben
oder einen RealAudio Stream. Besonders bei niedrigen Bandbreiten (unter 48 kbps)
ermöglichen diese Formate eine effektivere und damit besser klingendere Kodierung des
Audiosignals.
Die Umsetzung der Stufe 3 beruht im wesentlichen auf den in den vorangegangenen
Realisierungsstufen dargestellten Konzepten. Aus den Zielsetzungen im Konzept zur
Stufe 3 ergeben sich drei größere Probleme, die mit den bis jetzt vorhandenen Tools
nicht realisiert werden können.
Zunächst gibt es das Problem der „Wunschfunktion“: Den Hörern soll die Möglichkeit
gegeben werden sich aus einer Liste einen Wunschtitel zu bestellen, der dann
automatisch gespielt wird. Dies erfordert zum einen, dass alle im Archiv vorhandenen
Titel, die wünschbar sein sollen in einer Liste im HTML Format auf der Webseite
vorhanden sind. Weitaus komplexer ist es, den Wunsch an das Abspiel-System zu
65
übermitteln und eine automatische Wiedergabe zu realisieren. Denn dafür ist es nötig,
dass eine Verbindung von einer Webseite zum Player stattfindet, d.h. der Webserver
muss Steuersignale an das Abspielsystem senden. Es kommt erschwerend hinzu, dass
das Abspielsystem sich auf einem anderen Rechner befinden kann, der möglicherweise
auch ein anderes Betriebssystem hat.
Weiterhin stellt die Umsetzung des Sendeformats ein Problem dar. Hier muss ein Weg
gefunden werden, nicht nur das Abspielsystem mit einem Skript fernsteuern zu können,
sondern auch Funktionen einzubauen. Die Funktionen ermöglichen hierbei das
Reagieren auf Ereignisse, wie zum Beispiel Uhrzeit oder Titelwechsel und die
Interaktion mit der Playlist, wie beispielsweise „nächster Titel spielen“ oder „Liste
laden“.
Ein weiteres Problem, dass mit dem bisher benutzen System nur schwer zu realisieren
ist, sind die weitergehenden Zusatzinformationen zum aktuellen Titel. Es müssen dabei
nicht nur textliche Informationen verarbeitet werden, sondern auch Bilddaten. Eine
alleinige Verwendung des ID3v1 Tags ist deshalb nicht ausreichend. Hier wäre eine
Nutzung des ID3v2 Tags ideal, das die Speicherung eines solchen Datentypen-Gemischs
vorsieht.1 Jedoch ist eine Gebrauch dieses Tags problematisch, da , wie in Kapitel
3.2.2.2 -„Technische Umsetzung Realisierungsstufe 2“ schon erwähnt, eine korrekte
Verwendung noch nicht in einem entsprechenden Plug-in implementiert ist. Alternativ
muss deshalb auf extern zum aktuellen Titel gespeicherte Daten zugegriffen werden,
wobei die Daten dann in einer Datenbank oder unter anderweitigen Konventionen – wie
zum Beispiel Namenskonventionen und Verzeichnisstrukturen – gespeichert sind.
Die Verlinkung von Titel oder Interpret auf eine externe Datenbankabfrage ist auch
schon mit DoSomething möglich und stellt ebenso wenig ein Problem dar, wie das zum
Ziel gesetzte zusätzliche Streaming-Format.
Für die Realisierung der Wunschfunktion existieren einige Plug-ins – namentlich
RequestServer2, Song Requester und ShoutcASP – die entsprechende Funktionen
anbieten.2 Nach einigen Tests stellte sich jedoch heraus, dass RequestServer2 sowie
1. Eine Einführung in die Möglichkeiten des ID3v2 Tags ist unter folgendem Link zu finden: http://
www.id3.org/easy.html
2. Aktuelle Versionen und Informationen sind zu bekommen unter http://www.winamp.com/plugins/
66
Song Requester nicht stabil bis überhaupt nicht im System der Realisierungsstufe 2
laufen. Vor allem die notwenige Verschachtelung der Plug-ins wirkt sich sehr negativ auf
die Stabilität aus. ShoutcASP erfordert einen Microsoft IIS mit voller ASP
Unterstützung sowie die Installation weiterer Komponenten, so dass ein Einsatz des
Plug-ins sehr an einen Rechner mit entsprechender Ausstattung gebunden ist. Aufgrund
dieser Abhängigkeit kommt ShoutcASP nicht zum Einsatz.
Weitere Recherchen haben schließlich zu einem Tool geführt, welches Lösungen für alle
oben erläuterten Probleme bietet und für den nicht-kommerziellen Gebrauch als
Freeware erhältlich ist. Es handelt sich dabei um den Streaming Audio Manager (SAM)
von Spacial Audio Solutions.1 Im Einzelnen sind folgende Funktionen für
Realisierungsstufe 3 von Bedeutung:
•
Advanced Audio Tags (AAT) für Zusatzinformationen
•
Auto Song Queing (ASQ) für Playlist Rotation
•
Automated Requests für Titelwünsche
•
Automated HTML Output für Webseiten Erstellung
•
Windows Media Output für direkte Erzeugung eines Windows Media Streams
Diese Funktionen sind zum Teil als Plug-in realisiert, zum Teil aber auch fest in SAM
integriert. Im Vergleich zur Winamp-Lösung ergibt sich damit eine größere Stabilität des
Gesamtsystems und mehr Möglichkeiten, die realisiert werden können. SAM vereinigt
die bisherig umgesetzten Konzepte unter einer Oberfläche, dadurch wird nicht nur die
Bedienung einheitlicher, sondern auch die Qualität der einzelnen Module ist auf einem
einheitlichen professionellen Niveau. Aus diesen Gründen wird in Realisierungsstufe 3
völlig auf Winamp verzichtet und stattdessen eine Lösung mit SAM angestrebt. Der
Einsatz eines neuen Tools erfordert einige Tests und Konfigurationsarbeiten. Um den
automatisierten Sendebetrieb bei Radio GLF nicht unterbrechen zu müssen, wird
Realisierungsstufe 3 zu Testzwecken auf einem anderen Rechner installiert; das System
der Stufe 2 bleibt wie bisher aktiv.
1. Zu finden im WWW unter http://www.spacialaudio.com/
67
Im Rahmen dieser Arbeit ist eine umfassende Beschreibung und Anleitung zu SAM
nicht möglich. Die Bedienung und prinzipielle Vorgehensweise ist den bereits
vorgestellten Stufen sehr ähnlich, deshalb wird im weiteren Verlauf dieses Kapitels nur
auf die Eigenschaften eingegangen, die zur Umsetzung der Realisierungsstufe 3 von
Wichtigkeit sind. Die SAM Online-Dokumentation erklärt Schritt für Schritt die
einzelnen Funktionen von SAM und ist damit eine erste Hilfe.1
Abbildung 3-10, „Realisierungsstufe 4 - SAM Setup,“ auf Seite 69 stellt ein
vereinfachtes Schema der Realisierungsstufe 3 dar. Eine Screenshot des SAM
Benutzerinterfaces steht zentral in der Mitte der Abbildung. Zu Beginn einige
Erläuterungen zu den einzelnen Funktionsbereichen, die mit den Zahlen in den gelben
Quadraten markiert sind:
Zu 1: Dies ist der in SAM eingebaute Player. Die Funktion und Bedienung ist mit
Winamp nahezu identisch. Eine Besonderheit ist der „Line Rec“ Button, der per
Knopfdruck die Quelle für die Wiedergabe und damit für den Audiostream sofort auf
Line in der Soundkarte einstellt.
Zu 2: In diesem Bereich wird die aktuelle Playlist dargestellt. Titel können eingefügt und
angeordnet werden, so wie das in der Winamp Playlist auch der Fall ist. Alle die im
Moment in dieser Liste stehenden Titel werden beim entsprechenden Befehl in die
generierten Listen für die Wunschfunktion aufgenommen. Es können Playlisten im
m3u Format gelesen und geschrieben werden. Ein bedeutender Unterschied zu
Winamp ist hier, dass SAM absolute Pfadangaben zu den mp3-Files fordert. Bei
Winamp werden nur absolute Pfadangaben erzeugt, wenn die Playliste nicht auf
demselben Laufwerk wie die in der Liste enthaltenen Dateien abgespeichert wird.
Wird eine Winamp- Playliste mit relativen Pfadangaben in SAM geladen, so findet
und spielt SAM die Titel nicht.
Zu 3: Die Buttons oberhalb dieser Liste ermöglichen das Umschalten zwischen
Queuelist, Request Liste und History Liste. In der Queue werden die als nächstes zu
spielenden Titel angezeigt. Diese Titel können von der Playlist, von der
1. Die Dokumentation ist zu finden unter http://www.audiorealm.com/help/contents.htm
68
Templates bzw. generierte Webseiten
Playlist
Zusatz-Infos
Wunschliste
„Jetzt läuft“
Ticker
1
SAM – Streaming Audio Manager
4
5
2
3
asf-Stream
mp3-Stream
HTML-Seiten
Choosing t he Right
Choosing
Right Tool for the Job
Many Choices
Win AS Eo r
WAV to ASF
Au dio O nl y
Ty pe
Au dio + UR Ls
Win AS E
of AS F
Pi ct ur es
Au dio + I mag es
m
I ag e
PP T
AND
So ur ce
PP TI A ,
PP TA dd- O n
Vi deo
28. 8K b
ps
De si re d
B andwi d h
t
100 Kbps
100 +Kbps
IFYOUR
’ EN
I AHURRY
OR
VI Dt oA SF
MS Media Server
Shoutcast-Server
Webserver
Abbildung: 3-10 Realisierungsstufe 4 - SAM Setup
69
Wunschfunktion oder aus dem Jingles/Promos/Ads Bereich in die Queuelist
eingefügt werden. Ansonsten bietet sind bei dieser Liste die gleichen Funktionen wie
mit der Playliste möglich. Ist die automatische Annahme von Requests, also
Titelwünschen, deaktiviert, so sind eingegangene Wünsche in der Request Liste
aufgeführt. Werden die Wünsche allerdings automatisch angenommen, so werden sie
direkt in die Queuelist aufgenommen. In der History Liste werden schließlich alle
Titel aufgeführt, die SAM als letztes abgespielt hat oder abspielen wollte.1
Zu 4: Dieser Bereich ist eine verkleinerte Darstellung des Statistics Fenster und liefert
eine grafische Darstellung der aktuellen Hörerzahlen. Die Daten für diese Zahlen
stammen von den eingetragenen Shoutcast Servern.
Zu 5: In diesem Fensterbereich wird in Abbildung 3-10 das Skript der Playlist
Automation (ASQ) gezeigt. Hier kann das Skript editiert, gestartet und getestet
werden. Der blaue Markierungsbalken zeigt immer an, welcher Befehl des Skripts
aktuell verarbeitet wird.
Wie im oberen Bereich der Abbildung 3-10 zu erkennen ist, gibt es auch in dieser
Realisierungsstufe Templates, die mit aktuellen Daten versehen werden und
anschließend auf den Webserver übertragen werden. Die „Playlist“ Seite ist identisch mit
der Version aus Stufe 2, lediglich das Template ist ein wenig verändert worden, da die
Platzhalter-Tags bei SAM andere Bezeichnungen haben als bei DoSomething. Auf der
„jetzt läuft“ Seite werden die Informationen jetzt in einem Flash Movie dargestellt, denn
es müssen mehr Informationen auf derselben Fläche untergebracht werden. Flash bietet
hier mehr Gestaltungsfreiraum, insbesondere bei den verwendeten sehr kleinen Schriften
gibt es mehr Darstellungssicherheit. Die Informationen zum aktuellen Titel werden in
einer Laufschrift dargestellt, da die Schrift sonst zu klein wäre. Dafür hätte auch
alternativ ein Java-Applet verwendet werden können. Da aber auf der Radio GLF
Website schon mehrere Applets für das Pushtool und den Chat laufen, ist die Anzahl der
sicher funktionierenden Applets auf einer Seite schon erreicht. Das Flash Movie liest ca.
im 20 Sekunden-Abstand eine Datei vom Webserver, die die aktuellen Titeldaten enthält
und aktualisiert entsprechend die Laufschrift.
1. Versucht SAM ein Titel zu spielen, der dann aber nicht gefunden werden kann, so taucht dieser Titel
trotzdem in der History Liste auf.
70
Die Wunschlisten werden von SAM auf Basis einer Playlist erstellt, die alle im Archiv
verfügbaren Titel enthält. Es werden nach Interpreten alphabetisch sortierte Listen
erstellt, d.h. es gibt jeweils eine Seite von A bis Z, dazu noch eine Seite für 0 bis 9. Die
Seiten sind dabei untereinander verlinkt. Auf den Seiten gibt es für jeden aufgeführten
Titel einen „wünsch dir’s“ Link, wobei der Link als Sprungadresse den absoluten
Filenamen und die Adresse eines PHP Skripts enthält. Ein Klick auf den Link sendet also
den Filenamen an ein PHP Skript, welches dann ein Request- Befehl an SAM sendet und
anschließend ausgibt, ob der Wunschtitel erfolgreich bestellt wurde oder ob es Probleme
gab.
Die Seite „Infos zum aktuellen Titel“ ist auch eine HTML Seite auf Template Basis. Die
Erstellung dieser Seite benötigt die bereits erwähnten Advanced Audio Tags, um
zusätzliche Informationen zu speichern und anzuzeigen. Bei der Installation von SAM
wird auch ein AAT Editor installiert, mit dem sich zu einzelnen Titeln - oder ganzen
Playlisten auf einmal - Zusatzinformationen wie Texte oder Bilder erfassen und
abspeichern lassen. Im Editor gibt es verschiedene Felder zur Aufnahme der
Informationen. Die Felder haben jeweils Namen, die den Namen der Platzhalter-Tags in
den Templates entsprechen. Werden aus den Templates die fertigen HTML-Seiten
erstellt, dann wird im Falle von Textinformationen der Text direkt anstelle des
Platzhalter-Tags eingefügt; bei binären Informationen, um die es sich zum Beispiel bei
Bildern handelt, wird nur der Pfad zu den entsprechenden Daten auf dem Webserver
eingefügt. Die AATs werden in einem in SAM zu definierenden Verzeichnis
abgespeichert, wobei zu jedem bearbeiteten Titel eine AAT Datei erstellt wird. Der
Dateinamen entspricht dabei dem Dateinamen der mp3-Datei; die Endung lautet
allerdings nicht mp3 sondern aat, d.h. zu jedem bearbeiteten Titel kann ein
entsprechendes AAT gefunden werden.
Die Erfassung der Daten ist sehr zeitaufwendig, da die Zusatzinformationen zunächst
beschafft werden müssen und anschließend im Editor eingegeben werden. Deshalb sind
in Realisierungsstufe 3 die Zusatzinformationen beschränkt auf die Titel, die als fester
Bestandteil des Programmformats geplant sind. Der Editor ermöglicht es, vielen Titeln
auf einmal dieselben Informationen zuzuweisen, so dass in Stufe 3 für alle archivierten
Alben von „Depeche Mode“ für jeden Titel AATs mit einer Besprechung des Albums
71
sowie mit einem Bild des Albumcovers angelegt wurden. Außerdem gibt es zu jedem
Titel der Feature-Sendung – der Kinosendung „Cinewatch“ die vom Lernradio der MH
Karlsruhe zur Verfügung gestellt wurde – ein entsprechendes AAT. Bei den Hörspielen
gibt es zu den archivierten Folgen der Reihe „Die drei Fragezeichen“ ebenfalls
entsprechende AATs.
Für die Umsetzung des Sendeformats gibt es in SAM eine „Auto Song Queing“ (ASQ)
genannte Skriptsprache, mit der die zeit- und ereignisgesteuerte Wiedergabe von Titeln,
Playlisten und Jingles programmiert werden kann. Die Möglichkeiten von ASQ sind sehr
vielfältig und können nicht in ihrer Gesamtheit in dieser Arbeit behandelt werden.
Deshalb wird die technische Umsetzung anhand eines konkret erstellten Skripts erläutert.
Abbildung 3-11 zeigt das leicht gekürzte und bereinigte Skript, die Zeilenangaben
gehören nicht zum eigentlichen Skript sondern erleichtern nur die folgenden
Erläuterungen.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
72
// ChannelM Script by M.Zinsser
// File: ChannelM_edit.asq
ClearListID 1
LoadPlaylist P:\mixed_music.m3u
Randomize
RepeatOn
RequestsON
PreventTwiceOn
Play
Repeat
Repeat
OnAfter 2
InsertJingle
OnAfter 2
Until OnTime NextHalfHour
InsertHouseAd
Until OnTime 21:15:00
OnTime 22:00:00
ClearList
ShuffleOff
RepeatOff
RequestsOFF
LoadList 1,1,P:\cinewatch.m3u
Next
BottomOfQue M:\jinglepack\Jingles_Misc\Station ID.mp3
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
Repeat
OnQueEmpty
LoadRndSubDir 1,QueBottom,M:\musik\
InsertJingle
LoadRndSubDir 1,QueBottom,M:\musik\
Until OnTime 23:00:00
LoadRndDir N:\hoerspiele\3fragezeichen\
BottomOfQue M:\jinglepack\Jingles_Misc\Station ID.mp3
Restart
Abbildung: 3-11 ASQ Skript
Das Skript in Abbildung 3-11 beginnt mit einem Kommentar in den Zeilen 1 und 2.
Kommentare werden von SAM überlesen und dienen, wie üblich, nur der besseren
Wartbarkeit für den Programmierer.
Zeilen 4 bis 10 Initialisieren SAM und starten die Wiedergabe der Playlist
„mixed_music“.
Zwischen Zeile 12 und 19 läuft bis 21:15 Uhr eine Schleife, in der wiederum zwischen
Zeile 13 und 17 eine Schleife läuft. In der inneren Schleife werden immer zwei
Musiktitel gespielt, dann folgt ein Jingle – dies zählt auch als ein Titel –
anschliessend noch ein Musiktitel. Diese Schleife wird zu jeder halben Stunde
unterbrochen, Zeile 18 fügt ein Werbespot ein. Als Werbespots sind in
Realisierungsstufe 3 die Audioclips aus den MI2 Audiotechnik Praktika definiert.
Die äußere Schleife wird in Zeile 19 beendet, wenn das Skript nach 21:14 Uhr wieder
in Zeile 19 gelangt. D.h. es ist unter Umständen möglich, dass die innere Schleife um
21:14 Uhr nochmals neu durchlaufen wird, mit der Folge, dass erst um ca. 21:30 Uhr
Zeile 21 erreicht wird.
In Zeile 21 wartet das Skript bis 22:00 Uhr. Die maximal 45 Minuten zwischen Zeile 19
und Zeile 21 sind ein Sicherheitspuffer, damit gewährleistet ist, dass das Skript
pünktlich um 22:00 Uhr fortgesetzt wird. Solange sich das Skript in Wartestellung
befindet, spielt SAM weiterhin die aktuelle Playlist ab.
In Zeilen 22 bis 25 erfolgt eine Initialisierung zur Vorbereitung der Feature-Sendung, die
in Zeile 27 nicht in die Playlist, sondern in die Queuelist geladen wird.
Zeile 29 fügt an das Ende der Queuelist die Station ID1 hinzu.
73
Die Schleife zwischen Zeile 31 und 36 wartet in Zeile 32 erst einmal, bis die FeatureSendung abgearbeitet ist. Dann folgt ein zufälliger Musiktitel, ein Jingle und wieder
ein zufälliger Musiktitel. Ist es noch nicht 23:00 Uhr, wird die Schleife erneut
durchlaufen. Der Sinn dieser Schleife ist es, für den Fall, dass die Feature-Sendung
kürzer wie eine Stunde ist, dafür zu sorgen, dass die verbleibende Zeit bis 23:00 Uhr
mit Musik aufgefüllt wird.
Es folgt dann, frühestens gegen 23:10 Uhr mit Zeile 38 ein zufällig ausgewähltes
Hörspiel aus dem Archiv. Nach dem Hörspiel erklingt nochmals die Station ID.
Zeile 40 schließlich beendet das Skript und startet es erneut mit Zeile 1.
Dieses Skript ist eine relativ einfache Demonstration der Möglichkeiten von ASQ, denn
es sind komplexere Verschachtelungen und detailliertere Abfolgen möglich. SAM ist
allerdings in diesem Bereich noch nicht ganz ausgereift, weshalb sehr viele Tests der
einzelnen Abschnitte des obern erläuterten Skripts notwendig waren, um einen
Programmablauf zu erhalten, der den Zielsetzungen der Realisierungsstufe 3 gerecht
wird.
Diese Tests gaben Anlass zu einer organisatorischen Maßnahme. Da Testläufe des ASQ
Skripts immer nötig sind und diese aber nicht auf dem eigentlichen Sendesystem getestet
werden können – sonst würde das reguläre Programm gestört – müssen sie mit SAM auf
einem anderen System getestet werden. Dafür ist eine einheitliche Organisation der
Verzeichnisse und Laufwerksbuchstaben notwendig, so dass von jedem System aus die
einzelnen Titeln, Playlisten und Jingles über denselben absoluten Laufwerkspfad
erreichbar sind. In einem Windows Netzwerk, wie es im Studio des FB Digitale Medien
existiert, kann dies durch die Einrichtung von Netzwerklaufwerken auf den einzelnen
Systemen realisiert werden. Das Medienarchiv und das SAM System befinden sich bei
Radio GLF auf demselben Rechner, dennoch müssen auch hier die Netzwerklaufwerke
eingerichtet werden, selbst wenn ein direkter Zugriff auf die Dateien möglich wäre. Die
Tabelle in Abbildung 3-12 stellt die Zuordnung der einzelnen Netzwerklaufwerken dar.
1. Als Station ID wird ein Jingle bezeichnet, das als akustisches Erkennungszeichen des Senders gilt. In
diesem Fall ist es ein gesungenes „Radio G-L-F“.
74
Netzwerklaufwerk
Inhalt
Drive M
Media-Archiv01, das Archiv mit den Musiktiteln, bzw. Audiodateien
Drive N
reserviert für Media-Archiv02, falls eine weitere Festplatte oder ein
anderes System benötigt wird
Drive P
Playlists, Verzeichnis mit Playlisten
Drive W
WWW, direkter Zugriff auf den Webserver
Abbildung: 3-12 Tabelle Netzwerklaufwerke
Ein Vorteil dieser Zuordnung ist, dass keine Playlisten, Wunschlisten oder Skripte
geändert werden müssen, wenn das Medienarchiv auf eine andere Festplatte oder einen
anderen Rechner verlegt wird. Weiterhin werden Playlisten immer in einem eigenen
Verzeichnis gespeichert, d.h. auch Winamp speichert immer den absoluten Pfad zu den
Dateien, so dass diese Playlisten ohne Probleme in SAM gespielt werden.
Die Generierung der Webseiten erfolgt bei Realisierungsstufe 3 intern in SAM, auf
ähnliche Weise wie bei Winamp mit DoSomething Plug-in. Außer den Daten in den ID3
Tags werden auch die Daten aus evtl. vorhandenen AATs verarbeitet. Die Erzeugung der
Audiostreams erfolgt wie in Realisierungsstufe 2 mit hintereinandergereihten Plug-ins
im DSP Stacker. Zusätzlich zu den Shoutcast Plug-ins gibt es noch ein MS Windows
Media Audio Plug-in. Mit diesem Plug-in wird ein Stream im Microsoft-Format erzeugt,
welcher über eine MS Windows Media Server empfangen werden kann. Die dafür nötige
Konfiguration und Einrichtung von „Publishing Points“ würde den Rahmen der Arbeit
sprengen, eine entsprechende Dokumentation ist von Microsoft zu erhalten.1
3.2.3.3 Praktischer Einsatz Realisierungsstufe 3
SAM verfügt über eine eingebaute Recovery-Funktion, die beim Start von SAM oder
nach einem Neustart des Systems von selbst alle Funktionen wieder in Betrieb setzt,
vorausgesetzt, die Shoutcast und Windows Media Server sind in Betrieb. Über
entsprechender Einträge im Autostart Verzeichnis kann somit der Start des gesamten
Sendesystems mit dem Einschalten des Rechners realisiert werden. In dieser Hinsicht ist
das System der Realisierungsstufe 3 im Vergleich zu den Systemen der anderen Stufen
1. Microsoft, Windows Media 7, 1999, S. 14 ff.
75
am einfachsten zu handhaben. Allerdings ist das System auch so komplex, dass einige
Funktionen versagen können und ein manuelles Eingreifen nötig ist. Ansonsten erfordert
die Bedienung des Systems nur wenig Einarbeitungszeit, da vieles wie in Winamp
funktioniert. Vorteilhaft wirkt sich auch aus, dass mit SAM eine einheitliche Oberfläche
für Player, Playlisten, Shoutcast Server Statistiken (inklusive Relayserver) und Jingles
gegeben ist.
Die Konfiguration ist hingegen weit aufwendiger wie für die Systeme der früheren
Realisierungsstufen. Es sind mehr Pfade einzustellen, zusätzlich zu den Pfaden für das
Ein- und Ausgangsverzeichnis der Templates müssen Einstellungen für die AAT Dateien
und die Wunschfunktion gemacht werden. Der eingebaute „SAM Wizard“ ist dabei für
den Einstieg in die Konfiguration sehr hilfreich.
Weitaus aufwendiger als die rein technische Seite des SAM Systems ist die redaktionelle
Arbeit, die für einen ansprechenden Sendebetrieb geleistet werden muss. Es müssen
nicht nur attraktive Playlisten erstellt werden, sondern auch dafür gesorgt werden, dass
alle spielbaren Titel korrekt ausgefüllte ID3 Tags haben, sowie Zusatzinformationen für
die verwendeten Advanced Audio Tags. Zuletzt muss auch die Funktion des ASQ
Skripts beobachtet und gegebenenfalls korrigiert werden.
Für den Betrieb während der Radio GLF Live-Sendungen eignet sich das SAM System
auch besser als Winamp mit DoSomething Plug-in, denn die Aktualisierung der
Webseiten wird konsequent bei jedem Titelwechsel durchgeführt. Da die Queuelist über
eine Anzeige der Spiellänge der aktuellen Liste verfügt, kann sehr leicht live aus der
Playlist ein Musikblock mit vorgegebener Dauer zusammengestellt werden. Jingles
können per Druck auf die F2 Taste zufällig aus einer vorher definierten Liste eingefügt
werden.
76
Im SAM Softwarepaket ist auch eine „Remote Admin for SAM“ Anwendung enthalten,
mit der die wichtigsten Funktionen von SAM über eine IP/TCP Verbindung
ferngesteuert werden können. Wie in Abbildung 3-13 erkennbar, ist die Remote Admin
Oberfläche nahezu identisch zur normalen SAM Oberfläche. Mit dieser Anwendung
kann die Wiedergabe angehalten werden oder zum nächsten Titel gesprungen werden. Es
ist auch möglich, Playlisten zu editieren und die veränderte Liste wieder an SAM
zurückzuschicken. Vor allem aber ist eine Information über die Dauer und Spielzeit des
aktuellen Titels und der folgenden Titel fast ohne Verzögerung möglich. Moderation und
Technik können somit immer auf dem aktuellen Stand sein, die Zusammenarbeit des
Teams wird dadurch erleichtert. Weiterhin sind auch die aktuellen Hörerzahlen
übersichtlich dargestellt, so dass diese Daten leicht in die Moderation übernommen
werden können und sich verändernde Hörerzahlen als ein direktes Feedback zum
Programm gewertet werden können.
3.2.3.4Probleme
Das in diesem Kapitel vorgestellte System mit SAM als Hauptanwendung stellt ein sehr
umfangreiches und komplexes Webcasting System dar. Die vielen Funktionen und
Möglichkeiten sind alles potentielle Fehlerquellen. Tatsächlich läuft das System etwas
Abbildung: 3-13 SAM Remote Admin
77
unstabiler als die in Realisierungsstufen 1 und 2 vorgestellten Lösungen. Einige der
Plug-ins und Anwendungen sind erst im Beta-Stadium – wie beispielsweise der AAT
Editor oder das Windows Media Output Plug-in – so dass mit neueren Modulen eine
verbesserte Perfomance zu erwarten ist. Aufgrund vorkommender Abstürze einzelner
Komponenten des SAM Systems ist ein wartungsfreier, unbeaufsichtigter Betrieb über
längere Zeit möglich, aber nicht gewährleistet. Im mehrwöchigen Testbetrieb konnte
eine relativ betriebssichere Konfiguration des Systems erarbeitet werden. Vor allem der
Verzicht auf das Advanced Crossfading Plug-in sowie auf sehr kurze Audioclips von
unter 3 Sekunden erhöhen die Stabilität des Systems beträchtlich. Das Windows Media
Plug-in stürzt auch häufig, d.h. mehrmals pro Woche ab; das Gesamtsystem läuft aber
dennoch weiter.
Das für die Wunschfunktion notwendige PHP Skript stellt nicht direkt ein Problem dar.
Vielmehr ist es ein unschöner Nachteil, dass das Skript auf dem Server des SAM
Herstellers Spacialaudio Solutions läuft und sich dadurch der Kontrolle entzieht und der
SAM Anwender der Firma vertrauen muss. Außerdem stellt der lange Weg der
Steuersignale vom SAM System bei Radio GLF in die USA und wieder zurück eine
Verzögerung und mögliche Fehlerquelle dar. Im Internet ist ein PHP Skript verfügbar,
welches das original PHP Request Skript von Spacialaudio simuliert. Leider kam es
beim Testeinsatz zu Problemen, die nicht gelöst werden konnten, da es für dieses Skript
keinerlei Support gibt.
SAM Amp, der Player des Systems, hat eine ähnliche Plug-in Struktur wie Winamp.
Input, Output sowie DSP Plug-ins von Winamp sind kompatibel zu SAM Amp und
können verwendet werden. Leider können keine General Plug-ins verwendet werden, so
dass DoSomething nicht verwendet werden kann und damit das System der Stufe 3 nicht
zum System der Stufe 2 kompatibel ist und eine Umstellung, bzw. ein Wechsel der
Systeme mit größerem Aufwand verbunden ist.
Zu diesen Problemen technischer Natur kommen die schon erwähnten Probleme
inhaltlicher Natur. Der redaktionelle Aufwand für ein Vollprogramm mit allen
Zusatzfunktionen, die mit diesem System möglich sind, ist so hoch, dass er kaum von
einem kleinen Team von ein oder zwei Personen geleistet werden kann. Dazu kommt,
78
dass eine gewisse Einarbeitung in SAM und die benötigten Tools erforderlich ist, d.h. ein
intuitives Arbeiten ohne etwas Übung ist aufgrund der Komplexität nicht möglich.
Diese Probleme waren letztendlich der Auslöser für die Entscheidung, den
automatisierten Sendebetrieb von Radio GLF nicht auf das SAM System umzustellen,
sondern weiterhin das in Realisierungsstufe 2 vorgestellte System zu verwenden.
3.2.4.1Push it & GLF2
„Radio Station Web Site Visitors Show Great Interest in Side Channels”1
“’Audio Streamies’ are Even More Interested in Side Channels”2
Realisierungsstufe 4 beinhaltet konzeptionell nicht viel Neues. Durch die Realisierung
eines „Side Channels“ können die Stufen 2 und 3 zusammengeführt werden.
„Side Channels“ sind Spartenprogramme eines Senders, die sich in Inhalt und Format
vom Hauptprogramm unterscheiden. Sie sind auf eine kleinere Zielgruppen mit
speziellen Bedürfnissen zugeschnitten und erweitern somit die Zielgruppe des gesamten
Senders. So sind zum Beispiel Spartenprogramme denkbar, in denen entweder nur
Nachrichten und Wortbeiträge gesendet werden, oder Titel einer Musikrichtung oder
jeweils das gesamte Album der Woche (anstatt nur einzelner Titel im Hauptprogramm).
Die Hörer können auf diese Weise besser an den Sender gebunden werden, da ein
umfassenderes Programmangebot abrufbar ist. Denn bekommt ein Hörer bei „seinem“
Sender nicht was er sucht, wechselt er zu einem anderen. Bei Webcasting ist dies
technisch sehr einfach zu lösen, da im Internet eine fast unbegrenzte Menge an Kanälen
vorhanden sind im Gegensatz zu den begrenzt verfügbaren Frequenzen bei terrestrischen
Sendern.
In Realisierungsstufe 4 ist es deshalb ein Ziel, die Konzepte aus Realisierungsstufe 2 und
3 auf der Webseite von Radio GLF zu vereinen. Das Winamp System von Stufe 2 sendet
weiterhin alte Sendungen und Beiträge aus dem Archiv. Das SAM System aus Stufe 3
wird über einen Link als „GLF2 – ChannelM“ in die Webseite eingebunden. „M“ steht
1. Arbitron, Side Channel Study, 2000, S. 4
2. Arbitron, Side Channel Study, 2000, S. 5
79
hierbei für Musik oder Magazin, da das Programm von GLF2 hauptsächlich aus Musik
und einer Magazin oder Feature-Sendung besteht. Demzufolge sendet das SAM System
weiterhin das in Kapitel 3.2.3.2 beschriebene Sendeformat.
Eine weitere Zielsetzung der Realisierungsstufe 4 ist es, das GLF Pushtool an die
Automation anzukoppeln. Zur Zeit wird das Pushtool, wie in den vergangenen
Semestern, während der Live-Sendungen von einem „Pusher“ bedient, der Bilder oder
auch Links auf die GLF Webseite und damit zu den Hörern pusht. Die gepushten Bilder
sind dabei passend zur aktuellen Sendung. Zum Teil handelt es sich um Aufnahmen vom
jeweiligen Sendeort oder um Bilder, die für einen Sendebeitrag gemacht wurden. In der
restlichen Zeit, also vor und nach den Live-Sendungen, während das automatisierte
Programm gesendet wird, pusht eine spezielle Version des Pushtools in einem festen
Zeitabstand Bilder, die es zufällig aus einem definierten Verzeichnis auswählt. Die
Bilder, die dann auf der Webseite zu sehen sind, haben daher kaum einen
Zusammenhang mit dem automatisch gesendeten Programm. In Realisierungsstufe 4 soll
deshalb eine Synchronisation des Pushtools mit dem Sendesystem stattfinden. Das
bedeutet, dass immer die passenden Bilder zur jeweiligen Sendung oder zum jeweiligen
Beitrag gepusht werden. In Realisierungsstufe 3 werden mit Hilfe der AATs ebenfalls
Bilder zu einzelnen Titeln auf der Webseite angezeigt. Der Unterschied ist jedoch, dass
in Stufe 4 das Pushtool nicht statisch ein einziges Bild pro Titel anzeigt, sondern dass
mehrere Bilder nacheinander angezeigt werden können.
Die technische Umsetzung von GLF2 – ChannelM
erfolgt durch Platzieren eines Links auf der Radio GLF
Homepage. Abbildung 3-14 zeigt die Grafik, die zu
ChannelM verlinkt. Ein aktivieren des Links öffnet ein
Abbildung: 3-14 Logo GLF2
kleines Fenster, welches die „jetzt läuft“ Seite des SAM
Systems von Realisierungsstufe 4 enthält. Des weiteren
wurden einige Feineinstellungen an den Plug-ins vorgenommen, so dass das Programm
einen besseren und druckvolleren Klang bekommt und stabiler und sicherer läuft.
Ansonsten sind keine weiteren Änderungen nötig.
80
Die Anbindung des Pushtools ist hingegen komplizierter und nur mit einigem Aufwand
zu realisieren. In konventionellen Radio-Automationssystemen ist ein ähnliches
Synchronisations-Problem zu lösen, wenn verschiedene Aktionen, wie zum Beispiel für
RDS oder DAB Dienste, mit einem Titelwechsel getriggert werden müssen. In diesen
Systemen gibt es dann meist ein Modul, welches das On Air Automationssystem
überwacht und dessen aktuellen Status an angemeldete Dienste übermittelt.
Im Rahmen dieser Arbeit wurde zuerst ein entsprechendes Modul zu Testzwecken in
Flash entwickelt, um das prinzipielle Funktionieren des Konzepts schnell überprüfen zu
können. Die Flash-Anwendung funktioniert, hat aber den Nachteil, dass sie relativ
unflexibel und schwer zu warten ist.
In Realisierungsstufe 4 wird ein solches Überwachungsmodul schließlich in Form einer
Java Applikation entwickelt. Die Applikation überwacht eine zu definierende Datei in
definierbaren Intervallen und führt ein Systemkommando aus, wenn die Datei verändert
worden ist. Das Systemkommando, also ein Befehl, der zum Beispiel in der MS-DOS
Eingabeaufforderung eingegeben werden kann, ist in einer Konfigurationsdatei
gespeichert. Das Design der Applikation erfolgte auch mit dem Hintergedanken, dass das
Überwachungsmodul relativ einfach in das Pushtool eingebaut werden kann.
Im folgenden eine Beschreibung der implementierten Java-Klassen:
Die Klasse ChangeDetect ist die Hauptklasse der Applikation. Es wird eine Instanz der
ChangeDetector Klasse erzeugt. Die dafür notwenigen Parameter werden ChangeDetect
beim Aufruf in der Kommandozeile übergeben.
java ChangeDetect FileToCheck interval
Parameter:
FileToCheck
Pfad zu einer Datei, die auf Veränderung überprüft wird.
interval
Zeitangabe in Sekunden, die das Intervall für die Überprüfung angibt
Die Klasse ChangeDetector besitzt einen Konstruktor:
ChangeDetector(String filename, int sec)
Parameter:
filename
81
sec
Zeitangabe in Sekunden, die das Intervall für die Überprüfung angibt
Weiterhin benötigt die Klasse die Konfigurationsdatei ChangeDetect.ini. Als Inhalt hat
diese Datei eine Zeile mit dem auszuführenden Befehl, wie zum Beispiel:
java ImgPushCL GLF_IMAGES GLF_TEXT "D:\radio.glf\pushpics\Artist
- Title" -30 -10
Weiterhin gibt es vier Methoden:
public void run()Leistet die Hauptarbeit in der Klasse. Es findet die Überprüfung der
Datei statt, gegebenenfalls wird der Befehl in der .ini Datei ausgeführt. Anschließend
wartet der Thread um die im Konstruktor angegebene Zeit.
public void stop()Dies ist die Stop-Methode des Threads.
public void doIt(String exec) Diese Funktion initiiert den in der .ini Datei
angegebenen Prozess. Ist zu Beginn der Funktion der Prozess schon bzw. immer noch
am Laufen, wird er zerstört.
String IniReader()IniReader liest die Konfigurationsdatei und gibt deren Inhalt als
String zurück.
Die Klasse Modified besitzt einen Konstruktor:
Modified(String filename)
Parameter:
filename
Sowie eine Methode:
public boolean isModified()Die Funktion liest das Änderungsdatum der Datei aus. Ist
dies ein anderes als beim vorigen Auslesen wird true zurückgeliefert, ansonsten false.
Beim ersten Aufruf der Funktion wird immer false zurückgeliefert.
82
Abbildung 3-15
Automations-System
zeigt
die
Einbindung der Applikation in
Winamp mit DoSomething Plug-in
SAM
das
Gesamtsystem
von
Realisierungsstufe 2. Winamp
aktualisiert
mit
überwacht /
liest
File:
ChangeDetect.ini
DoSomething
Plug-in
erzeugt jedoch zusätzlich zu
ChangeDetector
den HTML Seiten bei jedem
ruft auf
Titelwechsel
Überwachungs-Modul
eine
aktuelle
Version der ChangeDetect.ini
Pushtool
Datei. In dieser Datei wird
derAufruf des CommandLine
Pusht Bilder
Pushtools gespeichert.
Das CommandLine Pushtool
Bilder
verzeichnis
erwartet unter anderem als
Parameter
Abbildung: 3-15 Realisierungsstufe 4 - ChangeDetect
einem
einen
Pfad
Verzeichnis
zu
mit
Bildern. Damit zu jedem Titel – wie Sendungen, Beiträge, Musiktitel – die passenden
Bilder gepusht werden können, müssen diese in einem speziellen Verzeichnis
gespeichert
sein.
Dabei
gelten
folgende
Konventionen:
Angenommen,
das
Hauptverzeichnis für die Pushbilder ist in C:\pushpics\ , dann muss es in diesem
Verzeichnis Unterverzeichnisse mit der Bezeichnung „Artist – Title“ geben. Für Artist
und Title werden die konkreten Daten des entsprechenden ID3 Tags eingegeben. Ein
vollständiger Pfad zu einem Bilderverzeichnis könnte beispielsweise so aussehen:
C:\pushpics\Philipp
Pfeiffer
-
KSG
Themenabende\ oder C:\pushpics\GLF
-
Sendung-2001-06-26\
Als zu überprüfende Datei wird die Konfigurationsdatei angegeben. Bei jedem
Titelwechsel enthält diese somit den aktuellen Pfad des zu pushenden Verzeichnisses,
und das Pushtool wird mit diesem Pfad aufgerufen.
3.2.4.3Praktischer Einsatz Realisierungsstufe 4
Die Umsetzung dieser Stufe erfolgte erst sehr zum Ende der Bearbeitungszeit dieser
Arbeit, so dass es keine Erkenntnisse über den praktischen Einsatz gibt. Durch den „Side
83
Channel“ GLF2 – ChannelM – ergibt sich im Grunde keine Veränderung des
Sendebetriebs, da dieser nebenher laufen kann und in Stufe 4 nur mehr in die
Öffentlichkeit gerückt wird.
Der Einsatz des Überwachungsmoduls ist nicht mit Mehraufwand verbunden, es muss
nach erfolgter Installation und Konfiguration lediglich zusammen mit dem
Gesamtsystem gestartet werden. Bei der bisherigen Vorgehensweise musste das Pushtool
vor der Live-Sendung beendet und nach der Live-Sendung gestartet werden, so dass sich
in dieser Hinsicht der Aufwand sogar verringert.
3.2.4.4Probleme
Das Überwachungsmodul funktioniert leider nur eingeschränkt. In Testläufen lässt sich
zwar ein Dummy-Pushtool mit den entsprechenden Parametern starten, beim
tatsächlichen Test auf dem Senderechner mit dem eigentlichen Pushtool passiert jedoch
gar nichts, das Pushtool wird nicht aufgerufen. Es werden keine Bilder gepusht, es wird
allerdings auch keine Fehlermeldung ausgegeben. Der Fehler liegt dabei anscheinend im
Aufruf des Pushtools durch die ChangeDetect Anwendung, denn es wird keine zweite
Java Virtual Machine gestartet. Im Rahmen dieser Arbeit war leider keine weitergehende
Fehlersuche und damit eine Behebung des Fehlers nicht mehr möglich. Die Applikation
ist daher für ihre vorgesehene Verwendung nicht brauchbar, eine Synchronisation des
Pushtools mit den aktuellen Titeln findet nicht statt.
Die Probleme, die mit GLF2 – ChannelM durch den Betrieb des zweiten Kanals
entstehen, beschränken sich hauptsächlich auf den redaktionellen und personellen
Bereich, wie sie in Kapitel 3.2.3.4 -„Probleme“ beschrieben sind.
84
Methodik -
4
Dokumentation und Analyse des Hörerverhaltens
4.1 Methodik
Die verschiedenen bei Radio GLF eingesetzten Server schreiben Logfiles, in denen alle
Benutzeraktionen aufgezeichnet werden. Im Rahmen dieser Arbeit sind insbesondere die
Logfiles des Radio GLF Webservers sowie der zwei Shoutcast Server von Interesse, da
diese ununterbrochen in Betrieb waren und so ersichtlich ist, wann und wie viele Nutzer
auf die Webcasting-Angebote von Radio GLF zugegriffen haben. Die Logfiles der
Shoutcast Server dokumentieren die Verbindungen zu den Streams sowie deren Dauer
über den gesamten Zeitraum des Sommersemesters 2001. Die Daten dieser Logfiles
werden kombiniert, denn im Rahmen dieser Arbeit ist die Bandbreite, mit denen auf die
Angebote zugegriffen haben, von geringerer Interesse als die zusammengefassten Daten
der Zugriffe.
Folgende Fragen können mit den Daten der Shoutcast Server beantwortet werden:
•
Wie ist die Entwicklung der täglichen Zugriffe auf die Streams im Verlauf des
Semesters?
•
Welche Zeit am Tag ist die Hauptzeit mit den meisten Hörern?
Mit der Antwort auf die erste Frage kann erkannt werden, wie beständig das Angebot
angenommen wurde und ob es einen Trend zu mehr oder weniger Webcasting-Konsum
gibt. Da nur dienstags live gesendet wird, können auch Aussagen über die Annahme des
Automatisierten Programms getroffen werden. Die Antwort auf die zweite Frage gibt
auch Auskunft darüber, wann außerhalb der Live-Sendungen zwischen 19:00 und 21:00
Uhr Interesse am Stream besteht. Weiterhin können daraus Anregungen für die
Gestaltung des automatisierten Programms entnommen werden.
Die Statistiken des Webservers sind als Vergleich zwischen den entsprechenden Monaten
der Vorsemester ausgelegt. So ist zum Beispiel November als zweiter Monat des
Wintersemesters mit April als zweiten Monat des Sommersemesters vergleichbar. Aus
den Statistiken können Rückschlüsse auf die allgemeine Popularität von Radio GLF
gemacht werden sowie erkannt werden, ob zu Zeiten, an denen nicht live gesendet wird
ein Interesse an der Radio GLF Webseite besteht.
85
86
U hrz e it
Abbildung: 4-2 Absolute Anzahl an Shoutcast-Verbindungen pro Stunde
23
22
21
20
19
18
17
16
15
14
13
12
11
10
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
00
00
00
00
00
00
00
00
00
00
:0
9:
8:
7:
6:
5:
4:
3:
2:
1:
0:
Anzahl
.0
.0
.0
4.
4.
01
01
E
E
rg
-20
24
4.
eb
ni
01 rge s
bn
.0
E
4
i
2 8 .0 1 r g e s
bn
.0
4 E
04 .0 rge is
.0 1 E b n
5
i
0 8 .0 1 r g e s
bn
.0
5 E
12 .0 rge is
.0 1 E b n
5
i
1 6 .0 1 r g e s
b
.0
5. E rg nis
20 0
e
.0 1 E b n
5
i
2 4 .0 1 r g e s
bn
.0
5 E
28 .0 rge is
.0 1 E b n
5
i
0 1 .0 1 r g e s
b
.0
6. E rg nis
05 01 e
bn
.0
6 E
i
0 9 .0 r g e s
.0 1 E b n
6.
i
r
13 01 ge s
b
.0
6. E rg nis
17 0
e
.0 1 E b n
6
i
2 1 .0 1 r g e s
bn
.0
6 E
25 .0 rge is
.0 1 E b n
6
i
2 9 .0 1 r g e s
bn
.0
6 E
03 .0 rge is
.0 1 E b n
7
i
0 7 .0 1 r g e s
b
.0
7. E rg nis
11 0
e
.0 1 E b n
7
i
1 5 .0 1 r g e s
bn
.0
7 E
i
1 9 .0 1 r g e s
b
.0
7. E rg nis
23 0
e
.0 1 E b n
7
i
2 7 .0 1 r g e s
bn
.0
7 E
31 .0 rge is
.0 1 E b n
7
i
0 4 .0 1 r g e s
b
.0
8. E rg nis
01 e
E bni
rg s
eb
ni
s
20
16
12
Ve rbindunge n
4.2 Dokumentation
V e rb in d u n g e n p ro T a g
180
160
140
120
100
80
Verbindungen
60
40
20
0
T age
Abbildung: 4-1 Absolute Anzahl an Shoutcast-Verbindungen pro Tag
V e rb in d u n g e n p ro S tu n d e
450
400
350
300
250
200
Verbindungen
150
100
50
0
Dokumentation -
2. Monat im Semester
Quelle: Radio GLF Webalizer Statistics, http://141.28.122.101/stats/
Abbildung: 4-3 Radio GLF Webserver Statistiken
87
4.3 Analyse
An den Spitzen in Abbildung 4-1 können klar die Live-Radiosendungen am Dienstag
erkannt werden. Erkennbar ist auch, dass an den Dienstagen mit TV-Sendung mehr
Verbindungen als sonst zustande kommen. An den übrigen Tagen gibt es nur sehr wenige
Verbindungen, an den Wochenenden wird ein meist Tiefpunkt erreicht. Im Juni und
Anfang Juli scheinen außerhalb der Live-Sendungen mehr Verbindungen zustande zu
kommen, als noch zu Beginn des Semesters.
Abbildung 4-2 zeigt die absolute Verteilung der Stream-Zugriffe im Tagesverlauf
während des gesamten Semesters. Wie zu erwarten ist aufgrund der Live-Sendungen von
19:00 Uhr bis 21:00 Uhr „Prime-Time“ bei Radio GLF. Beachtenswert ist allerdings der
erhöhte Zugriff eine Stunde vor und eine Stunde nach der Sendezeit der LiveSendungen. Ein weitere Höhepunkt ist gegen 14:30 Uhr zu verzeichnen, es scheint, dass
einige Hörer nach der Mittagspause für einige Zeit den Stream einschalten.
Wie die Grafiken der Webserver Statistiken in Abbildung 4-3 zeigen, sind deutliche
Entwicklungen im Verlauf der drei Semester und im Verlauf der einzelnen Semester zu
erkennen. Die Spitzen während der Live-Sendungen sind durchweg vorhanden.
Während zu Beginn des Sommersemesters 2000 außerhalb der Live-Sendungen keine
Aktivitäten zu erkennen sind, ist dies jedoch gegen Ende des Semesters der Fall. Dieses
Verhalten ist bei allen drei Semestern ähnlich. Im Sommersemester 2001 sind,
insbesondere im Vergleich mit dem Wintersemester 2000/01, schon zu Beginn des
Semesters deutliche Aktivitäten außerhalb der Sendungen zu erkennen, die im Verlauf
des Semesters zunehmen und die Spitzen zur Zeiten der Live-Sendungen glätten.
Anzumerken ist, dass alle Grafiken in einem unterschiedlichen Maßstab sind, die
höchste Säule entspricht immer 100%, der konkrete Wert kann am linken Rand der
jeweiligen Grafik erkannt werden.
Abschließend kann gesagt werden, dass die Popularität von Radio GLF im letzten Jahr
stark zugenommen hat. Das automatisierte Programm wird vor allem am frühen
Nachmittag sowie direkt vor und nach den Live-Sendungen konsumiert. Zu diesen
Zeiten sollte also das Programm möglichst attraktiv gestaltet werden.
88
Fazit -
5
Fazit und Ausblick
5.1 Fazit
Wie diese Arbeit gezeigt hat, gibt es bereits einige wenige Lösungen auf dem Markt, die
eine Automatisierung von Webcasting ermöglichen. Der Umfang und Anspruch der
jeweiligen Lösungen sind jedoch sehr verschieden.
Die großen und teuren Systeme stammen aus dem Bereich der konventionellen
Radioautomationssysteme. Sie sind auf die Bedürfnisse des Radioindustrie optimiert und
bieten oft nur wenig Möglichkeiten für innovatives Webcasting.
Die kleineren und günstigeren Systeme sind oft aus privaten Projekten entstanden und
bieten vielseitige Möglichkeiten für innovatives Webcasting, vernachlässigen aber dabei
die Bedürfnisse der Radioindustrie - wie Stabilität und Eignung für den Live-Betrieb.
Die praktische Umsetzungen im Rahmen dieser Arbeit führten zu einem breiten
Webcasting- Angebot von Radio GLF. GLF ist nun nicht nur 24 Stunden am Tag, 7 Tage
die Woche zu empfangen, sondern es sind auch Features implementiert, die den
Vergleich mit kommerziellen Radiosendern nicht zu scheuen brauchen. Die praktische
Umsetzung hat gezeigt, dass technische Probleme lösbar und mit vertretbarem Aufwand
in den Griff zu bekommen sind. Sie hat aber auch gezeigt, dass Webcasting neue
Anforderungen an das Content Management stellt, da viele Medientypen zusammen
möglichst
effizient
organisiert,
verarbeitet
und
organisiert
werden
müssen.
Konventionelle Redaktions- oder Content Management Systeme sind hier überfordert
und können nur in Teilbereichen eingesetzt werden.
Webcasting bietet viele Möglichkeiten. Doch welche sind sinnvoll, notwendig und
wirtschaftlich brauchbar? Es gibt viele Studien über die Gewohnheiten und Bedürfnisse
bei der Mediennutzung. Diese geben aber meist nur die Erfahrungen mit bereits
etablierten Medien wieder und sagen nichts über die Bedürfnisse aus, die durch die
neuen Möglichkeiten von Webcasting entstehen können.
5.2 Ausblick
Der Computer als Musik-Abspiel-Medium wird immer mehr akzeptiert, wie die
zunehmende Verbreitung von mp3-Files und der Erfolg von Napster zeigt. In absehbarer
89
Zeit wird den Nutzern ein schnelleres Netz mit mehr Bandbreite zur Verfügung stehen,
so dass die Zahl der Webcasting Konsumenten ansteigen wird.
In Intranets von Firmen ergeben sich vielfältige Anwendungsmöglichkeiten, wie
Webcasting für das Wohl der Firma eingesetzt werden kann. Betriebsinterne Fortbildung
mit Corporate Radio und Business TV sind hier die Stichworte.
Vor dem großen Durchbruch von Webcasting sind jedoch noch einige rechtliche Fragen
zu klären. In den USA hat der "Digital Millennium Copyright Act" dazu geführt, dass
Webcasting für die Anbieter sehr teuer wird und damit nicht mehr wirtschaftlich tragbar
ist. Ob dies den Erfolg von Webcasting verhindern kann, bleibt abzuwarten.
90
-
6
Literaturverzeichnis
ARBITRON (Hrsg.), 2000: Presseerklärung, New York, 29.01.2001, URL: http://
www.arbitron.com/newsroom/archive/1_31_01_1050.htm (17.5.2001)
ARBITRON/Edison Media Research (Hrsg.), 2000: Internet V, 2000, New York: URL
www.arbitron.com (17.05.2001)
ARBITRON/Edison Media Research (Hrsg.), 2000: Radio Station Web Site Content: An
In-Depth Look, 2000, New York: URL www.arbitron.com (17.05.2001)
ARBITRON/Edison Media Research (Hrsg.), 2000: The Side Channel Study, 2000, New
York: URL www.arbitron.com (17.05.2001)
ARBITRON/Edison Media Research (Hrsg.), 2001: Internet VI, 2001, New York: URL
www.arbitron.com (17.05.2001)
ARBITRON/Edison Media Research (Hrsg.), 2001: The Need for Speed, 2001, New
York: URL www.arbitron.com (17.05.2001)
CLEF, Ulrich (Hrsg.): Handbuch Radio Marketing, 1. Aufl., München: Clef Creative
Communications, 1995
EICHSTÄDT, Matthias, 1999: Internet webcasting: generating and matching profiles,
Wiesbaden: DUV, Dt. Univ.-Verl., 1999
FEIERABEND, Sabine / KLINGLER, Walter, 2000: JIM 2000 Jugend, Information, (Multi-)
Media, Baden-Baden: mpfs, 2000
HAMMERSTEIN, Konstantin von, 2000: Hit für Hit ein Hit, in: Der Spiegel, 2000, Nr. 19/
8.5.2000, S. 108 - 110
HILLEBRAND, Annette, 2000: Zwischen Rundfunk und Telekommunikation:
Entwicklungsperspektiven und regulatorische Implikationen von Webcasting,
Diskussionsbeitrag Nr. 211, Bad Honnef: Wissenschaftliches Institut für
Kommunikationsdienste, 2000
KLEINSTEUBER, Hans J. (Hrsg.): Radio, das unterschätzte Medium: Erfahrungen mit
nicht-kommerziellen Lokalstationen in 15 Staaten, Berlin: VISTAS, 1991
91
KURI, Jürgen, 2000: Virtueller Plattenschrank, in: c't, Nr. 22/00, (3.10.2000), S. 210 213
LAUTERBACH, Thomas: Digital Audio Broadcasting: Grundlagen, Anwendungen und
Einführung von DAB, Feldkirchen: Franzis, 1996
LIVE365.COM (Hrsg.): Newsletter "Memorial Day Weekend Edition" (26.05.2001),
URL: http://www.live365.com
MICROSOFT (Hrsg.), 1999: Windows Media 7 Walkthrough, Redmond: Microsoft,
1999
MILES, Peggy, 1998: Internet world guide to Webcasting, New York: John Wiley &
Sons, 1998
NULLSOFT (Hrsg.), 1999: SHOUTcast Documentation, 20.7.1999, URL: http://
www.shoutcast.com/support/docs/
index.phtml?language=english&layout=print&prevlayout=normal (26.3.2001)
NULLSOFT (Hrsg.), 1999: Writing Plug-ins, URL: http://www.winamp.com/nsdn/
winamp2x/dev/plugins/ (11.8.2001)
NULLSOFT (Hrsg.), 2001: Winamp Documentation: MPEG Input Plug-in, 2001 URL:
http://www.winamp.com/download/docs/
index.jhtml?_DARGS=%2Fdownload%2Fdocs%2Findex.jhtml.3 (13.8.2001)
ODDSOCK.ORG (Hrsg.), 2001: DoSomething Winamp Plug-in Version 2.8, (7.2.2001),
URL: http://www.oddsock.org/tools/dosomething/ (22.3.2001)
SCHÄFER-SCHÖNTHAL, A.: WebRadioBeschreibung (5.2.2001), URL: http://
141.28.122.101/auftrag001.htm (5.4.2001)
STEINMETZ, RALF, 1999: Multimedia-Technologie, 2. Aufl., Berlin; Heidelberg:
Springer, 1999
STOLL, Gerhard: Broadcast@Internet: Die Perspektiven für den Rundfunk?,
Technisch-wissenschaftliches Kolloquium des IRT, 22. März 1999, Institut für
Rundfunktechnik, München
SWR (Hrsg.): DASDING: für die pressefuzzis, Baden-Baden: SWR, 2001
92
-
SWR (Hrsg.): Presse-Spiegel: 1 Jahr DASDING, Baden-Baden: SWR, 2001
WEGNER, Ralf / BACHMEIER, Claus, 2000: Streaming Media im Business Bereich,
München: Addison-Wesley, 2000
93
94
Anhang A
A Produktionsrichtlinien
Produktionsrichtlinien v1.21
1.
1.1.
Warum Produktionsrichtlinien?
Die folgenden Richtlinien sollen für einen Standard sorgen, der sich in einer einheitlichen technischen Qualität der einzelnen Beiträge auswirkt. Außerdem soll die
Archivierung der Beiträge, sowie insbesondere deren Auffinden vereinfacht werden.
Auch hinsichtlich eines Mulitmedia-Content-Management-Systems, das in nachfolgenden Semestern eingerichtet werden soll, muss ein Standard eingeführt werden.
2.
2.1.
Audio
Pegel
Schon bei der Aufnahme sollte auf eine sehr genaue Einstellung der Pegel geachtet
werden, um Übersteuerungen, aber auch zu geringe Pegel, zu vermeiden. Gegebenenfalls ist ein Limiter einzusetzen. Nach der Aufnahme kann der Ton weiter optimiert
werden:
2.1.1.
Dynamik-Komprimierung
Aufgrund der Wirkungsweise der Datenkomprimierung bei Streaminganwendungen kann eine bessere Tonqualität beim Hörer/Anwender erreicht werden, wenn
deutliche Dynamik-Kompression eingesetzt wird. Besonders bei Sprache und
leisen Musikpassagen sollte relativ aggressiv komprimiert werden, um eine noch
gute Verständlichkeit auch bei niedrigen Bandbreiten zu erhalten.
Bei Multiband-Kompressoren (wie z.B. in Samplitude Studio oder Finalizer) halten
sich auch die Nebeneffekte in Grenzen. Bei allen modernen Soundeditoren können Plug-ins mit entsprechenden Fähigkeiten eingebunden werden (z.B. L1 Ultramaximizer und C1 Compressor als DirectX Plug-Ins aus dem Native Power Pack).
Auch die Studio-Ausrüstung (ProTools) kann eingesetzt werden.
Bei aktueller Pop/Rock Musik von CD ist keine weitere Komprimierung nötig. Handelt es sich jedoch um klassische Musik oder Jazz sollte unbedingt komprimiert
werden.
2.1.2.
Normalisierung
Alle vorproduzierten Beiträge sollten (nach der Kompression) auf einen Pegel von
99% bis 100% (oder –0.3dB bis 0 dB) normalisiert werden, damit ein einheitlicher
Lautstärkepegel bei allen Beiträgen gegeben ist.
2.2.
EQ
Der Klang kann für Streaming optimiert werden, wenn der Präsenzbereich (2...3 KHz)
sorgfältig auf gute Verständlichkeit geregelt wird. Es sollten genügend Höhen
vorhanden sein, es darf jedoch nicht zu einem Zischen kommen. Zischlaute beanspruchen eine hohe Bandbreite bei der (Daten-)Komprimierung und wirken sich beim
Downsampling auf z.B. 22 oder 16 kHz sehr negativ auf die Verständlichkeit aus.
2.3.
Format
Alle Beiträge sollten spätestens nach der Sendung als mp3-File vorliegen. Da die
Beiträge evtl. noch weiterverarbeitet werden (z.B. Konvertierung nach Realmedia
oder MS .asf) sind folgende Parameter optimal:
95
- 44 kHz Samplingrate
- Konstante Bitrate (CBR) von 128 bis 192 kBit/s, bei Mono die Hälfte davon
- MS Stereo oder Stereo bei Stereoproduktionen, Mono bei Monoproduktionen.
Mp3-Konverter mit guter Qualität sind z.B. Xing-Audiocatalyst ab Version 2.0, die original Fraunhofer Tools (Im Studio in CoolEdit) oder Lame.
Weiterhin sollte das ID3v1 Tag des fertigen Files ausgefüllt werden (alt+3 in Winamp)
Alle Jingles und Trailer sollten als mp3 oder WAV auf dem Tonstudio-Rechner oder im
glf-Incoming vorliegen.
2.4.
3.
3.1.
Musik
Musik aus der Konserve sollte möglichst als mp3 (min 128 kBit/s) vorhanden sein, kann
aber auch von Audio-CD oder als WAV (44,1 KHz/16 Bit) eingespielt werden. Um den
Sendeablauf zu vereinfachen (indem weniger Geräte bedient werden müssen) und um
ein Archiv aufzubauen ist längerfristig eine komplette Umstellung auf mp3 zu realisieren. Bei Musik ist ebenfalls auf eine minimale Eintragung der ID3-Tag Daten, wie
Titel und Interpret, zu achten.
Video
Bild
Eine sehr gute Anleitung um optimale Bildqualität für Streaming zu erhalten findet
sich im „Producers Guide to Live Webcasting“. Hier nur kurz die wichtigsten Tipps:
- Für helle Beleuchtung sorgen (kein Bildrauschen!)
- Nur langsame Bewegungen (mit der Kamera und im Bild), vor allem keine animierten
Schriften oder Video-Effekte mit Wipes. Ebenso sind Zooms und Schwenks mit Vorsicht zu
genießen
- möglichst viel Kontrast
Generell ist es empfehlenswert einen kurzen Clip im gewünschten Zielformat zu komprimieren und dann entsprechende Korrekturen im Original durchzuführen.
Als Video vorproduzierte Filme oder Animationen erscheinen im Streaming oft zu
dunkel, evtl. bearbeiten.
3.2.
Ton
siehe oben, Punkt 2
Wer den Aufwand meiden möchte, sollte zumindest den Soundtrack im Videoeditor
auf 99 bis 100% normalisieren. Das Ergebnis wird aber meist besser, wenn man die
Audio-Spur extrahiert, in einem Audio Editor bearbeitet und dann wieder zum Bild
anlegt.
3.3.
Format
Der fertige Beitrag sollte zur Sendung als digitales Video-File zur Verfügung stehen.
Kassetten (VHS, S-VHS, Beta) sind möglich, aber längerfristig zu vermeiden. Ein im
Moment noch optimales Format ist ein MPEG-File gemäß VideoCD– Spezifikation:
- 44 kHz Stereo Audio, 224 kBit/s
- 352 x 288 Pixel Videoauflösung, 25 FPS, 1150 kBit/s
- Gesamtdatenrate ca. 1.4 Mbit/s (MPEG1)
Im Moment werden die Beiträge während der Sendung noch von Betacam abgespielt.
Um also die Beiträge zusätzlich noch auf Band spielen, sind folgende Einstellungen
96
Anhang A
nötig:
- 44kHz Stereo Audio
- 768 bzw 720 x 576 Pixel, 25 fps AVI
- Motion JPEG (MJPEG) AV-Master-CODEC (gibt’s in glf-incoming/tools)oder DV Codec
Insgesamt ergibt sich daraus in etwa VHS Qualität, was für Streaming ausreichend ist.
MPEG1 Files werden von den meisten Videoeditoren und Encodern als direktes Quellformat akzeptiert, die Beiträge können also auf einfache Weise weiterverarbeitet
werden.
Als MPEG-Encoder mit einer sehr guten Bildqualität empfiehlt sich der Panasonic
MPEG Encoder, den es als Plug-in für Premiere gibt. Filme können direkt, ohne Umweg
über AVI, konvertiert werden. Eine gute Bildqualität hat auch der XING MPEG Encoder.
Alternativ eignet sich auch ein AVI im MPEG4 (MS V2, V7) oder DivX Format, wobei der
Konvertierungsvorgang zur Zeit noch etwas kompliziert ist und auch der Codec nicht
auf allen Rechnern vorhanden ist. Die Datenrate/Dateigröße bei MPEG4/DivX ist aber
bei gleicher Qualität wesentlich geringer, weshalb v.a. für längere Mitschnitte fürs
Archiv diesem Format der Vorzug gegenüber MPEG 1 gegeben werden sollte. Wichtig
bei AVIs im MPEG4 Format ist, dass auch der Ton datenreduziert, also z.B. ins mp3Format gewandelt wird. Unkomprimierter Ton benötigt in etwa die gleiche Datenrate
wie ein MPEG1 Stream insgesamt.
Vom WindowsMediaEncoder erzeugte Dateien in MPEG4 (MS V2/V7), also .asf und
.wmf-Files, eignen sich jedoch nur sehr bedingt zur weiteren Verarbeitung, da diese
Formate nicht mehr in ein Videoeditor importiert werden können.
Spätestens zum Ende jeder Sendung müssen die Filmbeiträge in einem dieser digitalen
Formate für das Archiv zur Verfügung stehen.
4.
4.1.
Push-Tool
Bilder, Fotos
Bilder und Grafiken zu den Beiträgen können live in den Browser gepusht werden. Dies
bietet sich vor allem bei Radio-Sendungen an. Dazu sollten sie in der richtigen Reihenfolg numeriert sein und in einem eigenen Verzeichnis gesammelt auf glf-Incoming
unter dem Sendedatum gespeichert sein. Außerdem ist dem Filenamen noch eine Vorsilbe zu geben, die den Bildern eine Zuordnung zum entsprechenden Beitrag ermöglicht und Idealerweise auch noch nach dem Sendeplan ordnet. Als geeigneter
Dateinamen ergibt sich so z.B. B01_01_Meine_Tante.jpg .
Hier sind nur GIF und JPG möglich, sie sollten stark komprimiert sein (z. B: in Photoshop Qualität 4 bis 6), die geeignete Bildgröße ist 320 *240 (max. 352 * 288), somit
sollte ein Bild nicht grösser als 15 kB sein.
Für die Archivierung von Audio-Beiträgen mit Slideshow bietet sich Flash an, aber
auch Windows Media und Real bieten solche Möglichkeiten (ASF-Skript/SMIL).
4.2.
URLs pushen
Es ist möglich, in Beiträgen auf andere URLs Bezug zu nehmen und diese in bestimmte
Frames der glf-Seite oder neue Fenster zu pushen. Damit kann man den Zuschauern
direkt Inhalte zeigen, die man sonst langatmig erklären muss. Die Liste der URLs sollte
zeilenweise in einem Textfile vorliegen. Diese Möglichkeit ist aber noch im Experimentierstadium und muß spätestens am Montag vor der Sendung getestet werden.
5.
5.1.
Allgemein
Ablage der Dateien/Vorbereitung der Sendung
97
5.2.
5.3.
98
Alle Beiträge, Bilder, Texte, Playlisten und Musik sind bis spätestens 4 Stunden vor der
Sendung auf glfservice>glf-incoming im Verzeichnis der jeweiligen Sendung zu speichern. Dort wird alles zentral gesammelt und dann kurz vor der Sendung auf die jeweiligen Ausspiel-/Sende-/Push-Rechner kopiert.
Nach der Sendung ist auch eine Kopie des Sendemitschnitts im entsprechenden Verzeichnis auf glf-incoming abzulegen.
Naming-Conventions
Die Filenamen sollten sinnvoll und nicht kryptisch gewählt werden. Vom Filenamen
sollte auf den Inhalt sowie auf das Sendedatum geschlossen werden können, z.B.:
Beitrag - ErstSemFete_SS01.mp3
Eventuell noch ein Textfile mit Zusatzangaben (Autor, Mitwirkende, Datum, Dauer,
Copyright, etc.) anlegen.
Verzeichnisnamen für Push-Bilder:
Die Push-Bilder sind in einem Verzeichnis abzulegen, dessen Namen aus den Angaben
des dazugehörigen mp3-Files gebildet werden. Dabei ist für die Benennung das
Schema „Artist – Title“ abzuwenden, wobei für „Artist“ und „Title“ die entsprechenden Daten aus dem ID3 Tag einzusetzen sind.
Beispiele:
F:\pushpics\Philipp Pfeiffer - KSG Themenabende\
F:\pushpics\GLF - Sendung-2001-06-26\
Archivierung
Sinnvoll ist es ein oder zwei CDs zu brennen, auf denen sich jeweils die Materialien
der gesamten Sendung befinden, also Audio, Video, Bilder, Texte und Sendeplan.
Die Dateien sollten sich in Verzeichnissen mit dem entsprechenden (sinnvollen)
Namen befinden (z.B. Beiträge\BeitragXY\Audio, Moderationen, Musik,
Jingles).
Dies ist eine geeignete Aufgabe für den „Chef vom Dienst“ .
Anhang B
B
Inhalt der CD
Die dieser Arbeit beigelegte CD enthält elektronisch erfasste Quellen und Dokumente,
die verarbeitet und z.T. zitiert worden sind. Weiterhin sind Arbeitsdateien und teilweise
lauffähige Systeme der einzelnen Realisierungsstufen enthalten, sowie eine kleine
Sammlung an Plug-ins und Tools
Die Verzeichnisse im Einzelnen:
Quellen: enthält alle zitierten elektronischen Quellen, die Unterverzeichnisse geben den
jeweiligen Autor oder Herausgeber an.
PDF: PDF Versionen dieser Arbeit
Tools: Eine Sammlung an Plug-ins und Tools, die für Webcasting geeignet sind.
Praktische Umsetzungen: Zu jeder Realisierungsstufe gibt es einen Unterordner, der
Dateien enthält, die den jeweiligen Entwicklungsstand dokumentieren.
99

Webcasting: Möglichkeiten der Automatisierung

Transcription

Similar documents

Contrailcirrus und Schwefel

Winter 2015 - Franz Sales Haus

Multicast-Proxy-Server für Audio-Live-Streams

Rights Catalogue Rechtekatalog

Nº23Live - Tutorial - Audio Streaming, eigenes Web Radio mit

Digitale Filter - Lehrstuhl für Nachrichtentechnik

Tendenz 2/2012

Zusammenfassung - Musikwirtschaftsforschung