h a l f b a k e r yWe are investigating the problem and will update you shortly.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I find it hard to believe that this is neither baked nor on the Halfbakery, so anyone wishing to disabuse me please do so.
On the BBC website's "listen again" pages, it's possible to select programmes broadcast up to a week previously. This is particularly helpful when broadcasts have been made
at times when one is unable to listen to the radio. Other websites allow users to select various audio presentations as streaming media, and music internet radio stations have playlists. There are also podcasts. What seems to be missing from all this is a portable audio device that can be used to access audio on demand. If DAB radios had the facility to communicate with stations, a menu or other user interface could be provided to select such broadcasts, either as streaming media or as wireless podcast downloads.
There would be a potential bottleneck if streaming were involved, so maybe podcasts would be better. Performance rights could be handled by a system similar to Pay As You Go on mobile telephones, or if desired, a direct debit system. The media could be designed in such a way as to expire after a certain period.
[link]
|
|
Can you go into a little bit more detail as to what your idea is? |
|
|
Broadcast technologies, by their nature, are sent to everybody. This makes the notion of content-on-demand through a broadcast system like DAB a big challenge. |
|
|
You have to remember that wireless interfaces have restrictions on bandwidth. It is ok for fixed-line technologies, they have huge bandwdith through optical means and if the capacity ever becomes insufficient you can always lay down more cable. You can't just make more frequencies available in thin air! So if you are broadcasting an audio file for one person (or a group) then you have to multiplex that with any signals for other people (whether you wait for a new timeslot or use another frequency). |
|
|
The delivery of multimedia content on demand in a wireless environment is a HUGE area of research. The very uplink that you are talking about is in itself an area of vibrant research: Convergence of cellular and broadcast technologies is a very widely researched topic. |
|
|
What i've said sounds somewhat confused. My idea is that there should be a portable audio device which can receive digital radio signals and also transmit some form of digital radio signal which communicates with a server carrying a number of audio files and running an application which provides the user with a menu, like an FTP server menu, listing files which can be downloaded or streamed from that server, this menu being displayed on the device itself. I appreciate that wirelessly streaming a large number of audio files could present a bandwidth problem, so i was trying to think of ways to get round this. My first thought, expressed in the idea, was that it could be done by downloading the entire file at a particular time, but while writing that, i've decided that a bit torrent-style system could solve this problem. The file transfers could occur while the audio device was not being used to listen to audio files. This would solve the problem of not being able to listen to programmes broadcast at inconvenient times.
There could be a problem with royalties, but this could be solved by the use of a mobile 'phone type "pay as you go" system in connection with files that become unplayable after a certain number of days. On the other hand, you could just forget this bit and have the whole thing free. If there were enough devices in use, a bit torrent like system could work. It does seem though that it is on the way to being baked. Is there a name for this sort of thing? Is it done routinely with speech as well as music? Would it help if the speech was compressed through a lossy algorithm to telephone quality? Would that mean the bandwidth problem i expect would be solved? Does that make any more sense? |
|
| |