Reboot FM

From smultron.org

Jump to: navigation, search

Reboot FM is a non-commercial radio from Berlin. Reboot FM has been sending on 88.4 MHZ since May 2010, from a radio studio in Haus der Kulturen, a public art center.

rebootfm_theproblem.png

The Problem

The problem with the 88.4 MHz frequency is that it is on the far side of the spectrum, in a frequency range that is clogged by other radios. Both regional and state radios are using frequencies close to 88.4 MHz to cover Berlin and surroundings. The polish border is not far, and at least one polish radio is broadcasting on the same frequency. In order not to jam the other radios, Reboot FM is broadcasting with a very low power, so it is actually quite difficult to receive in the north of Berlin.

Not only the radio spectrum is clogged, so is the schedule. reboot FM shares this frequency with several other non-commercial radio initiatives. Reboot FM was awarded a 2 days a week slot. This makes it difficult to tune for casual listeners.

The solution (sort of)

The Reboot FM crew is very experienced in streaming, as they offer their expertise through a separate company specialized in broadcasting events through the web. So for them the obvious solution was to compensate for the clogged spectrum by offering a live stream, and to compensate for the clogged schedule by offering a podcast.

A major problem at Reboot.FM as it is today, is that the same data has to be input several times through different interfaces, and sometimes manually converted. This is the case for audio file metadata, schedules and playlists,

reboot_dfd_0b.png

Looking at the data flows inside the Reboot.FM system, it becomes apparent that the system lacks a unified data repository. This is a classic problem aka the 'Silo Concept'. Each of the subsystems used in the Reboot.FM workflow uses it's own data mapping. This mapping is the product of the logical structure of the data in each subsystem, which is itself the product of different needs and design decisions in each individual process. For example: Wordpress stores playlist data in it's database, but the same data is copied (manually) in ID3 tags and coded in the audio file name. The Silo Concept leads to fragmented data storage and poor communication between components.

A software solution for this type of problem should provide a unified data storage for all schedule, playlist and archived data, as well as a unified user interface for controlling website, stream and podcast.

Personal tools