Track Separation Detection for Streaming Media? 22
manavendra asks: "I have been using a couple of streaming audio rippers for about a week now (StreamRipper and StationRipper, most notably), but most of them seem to be afflicted with the same problem - inconsistent track separation. I've read about the Shoutcast Metadata Protocol, but I haven't properly understood how the silence-detection mechanism of track separation works. There have been users who have observed that since most tracks are skewed by a few seconds (depending upon the radio station), they advise adding provision to delay or advance the timing. Has anyone implemented a better mechanism, since basing breaks on silence detection seems dodgy in first place? Can someone can shed some light on the inherent problems of reliable track separation?"
Lets think about this (Score:4, Insightful)
Re:Lets think about this (Score:1)
For God's Sake..... (Score:4, Insightful)
Of course I personally dislike many of those radio stations that just sequence a playlist on winamp and let it run. Gaps between tracks just doesn't make good radio, it's lazy on the part of the 'DJ'.
Yes there are better ways, depending on the metadata protocol (shoutcast has a really broken metadata system) and on the source streamer. I wrote code for it a long time ago, but it was just at odds with any notion that I was a music fan.
Re:For God's Sake..... (Score:1)
I dont mind paying for tracks, but as I have had this discussion in the past with several othere ppl (especially related to those RIAA lawsuits), but dont you think the recording industry makes you pay for the whole album when only a single track is what yo
And if you've got digital cable audio channels... (Score:3, Insightful)
If you had software that did that and combined it with a ripper, you could leave it running all day and have a repository of free (well, already-paid-for) legally owned music.
Hmph (Score:3, Funny)
If God had meant us to separate tracks, He wouldn't have invented crossfading!
Silence Detection activated (Score:2)
Did you think about your bills, your ex, your deadlines...
and so on.
I bet "2:35 of silence" would be a whole lot of tracks.
Re:Silence Detection activated (Score:1)
Nah. Zero tracks. New track starts on the leading edge of non-silence. So, the "track" containing "2:35 of Silence" would get silently merged with the gap that precedes it and follows it. It will also get silently dropped.
--Joehere's the skinny (Score:5, Informative)
the separation doesn't come from detecting silence, it comes from winamp (or a supporting media player) TELLING the server that the track has changed, and what the data is for the new track. the server then sends this down in the stream along with the music and that's how you see what's playing.
now, on stations that have a lot of listeners, the metadata seems to start coming down AFTER the song actually starts, which cuts off the front of the song, and at the end of the track you hear 10-15 seconds of the next song. Club 977's stream does this VERY bad, for example.
other than resplitting the files and joining them again there doesn't seem to be any easy way to correct the mis-separation.
you could force the stream ripper to check the metadata every single second (if the software supports it) so that it will catch the new data as soon as it comes down, but if the server only updates this data every 15 seconds there is nothing you can do. if i were a server operator i would do this purely because it would make it difficult to cleanly rip my stream, something i think that i would like.
Re:here's the skinny (Score:2)
Also the new patched version (check the forums) supports http authentication.
I also burn the tracks in order of ripped, so if its ever off by a few seconds of metadata, it still plays back without the annoying changes.
Re:here's the skinny (Score:2)
As the FAQ [sourceforge.net] says (the Why does one track bleed into another), streamripper uses a combination of metadata and silence detection (upon metadata track change, it searches for the most recent silent point and splits there). So even if the metadata is a few seconds late, there shouldnt be a problem. The problem is with stations that use crossfading, or some other technique that means there is no silence between tracks.
Also, I really don't see the problem with allowing people to rip streams however, except for
Re:here's the skinny (Score:1)
Its interesting that you mention that track separation is also assisted by the media player requesting the metadata for a new track. I did notice winamp changing the track title a few seconds before the actual track started. May this happens because of cross-fading?
Well, the radio stations that I listen to, apparently the meta-data comes BEFORE the song actually starts, even though they have a fairly large number of listeners...
Still, thanks anyway. I need to examine the proto
Shoutcast Metadata (Score:3, Informative)
The shouldcast metadata protocol works by inserting special data every X (usually 8192) bytes. The data looks something like "StreamTitle=blah; StreamUrl=bleh".
Since 8192 bytes is about half a second at 128Kbps (128000/8192/8 = 1.95), a detection of a change of track using this method is usually pretty accurate.
Re:Shoutcast Metadata (Score:1)
I wonder why the rippers that I use have a problem in track separation then. I will implement something of my own this weekend and post an update later
Cheers
Re:Shoutcast Metadata (Score:1)
Personally I'd just fire up a sniffer (e.g. tcpflow) to see what the request looks like. Or point the ripper to a listening socket that you have control over to see what it sends. Or perhaps grep the sourcecode for "Icy".
Re:Shoutcast Metadata (Score:1)
how to get perfect track separation (Score:2)
In a semi(?)-related note (Score:1)
I know you can separate by frequency using Fast Fourier Transformations.... But that does not compensate for the fact that, for example, the highest note on a bass guitar is higher than the lowest note on a normal guitar.