I couldn't find such a list on this forum either.

Shoutcast obviously has a large directory of streams, but you need a developer ID to access the database.

Shoutcast has one of the best internet radio station directories out there (54,000+ stations) but 1) the directory only contains Shoutcast stations and 2) Shoutcast has gone full-blown proprietary on use.  Like you mentioned, accessing the Shoutcast Radio directory requires a Developer ID which requires that you register and sign a license agreement.  Even with a Developer ID, I've read from many many sources that you are restricted to a limited number of times you can access the directory per day (~20) before the API stops working.

Screamer Radio has a large database of streams as well. The folks over there can probably help you out.

Screamer Radio has a decent directory.  4,007 stations at last count.  It appears that the database is being updated, just not very frequently.  According the forum (2009 post), the dude/dudette who was updating the database has gone Sarah Palin (i.e., rogue).

What exactly are you seeking, the tabbed MySQL flat file export? or access to the MySQL DB?
There is Screamer-Radio, Radio Sure, and inLight Radio all have a large selection of stations...
Have a good one

The players and station directories for Radio Sure and inLight Radio are so similar that I wonder if they are not from the same developer.  The directories are excellent.  There are ~20,000 stations listed.

It's pretty easy to use a copy of the databases from any one of these vendors but 1) the data would be static (i.e. no legitimate way to provide updates) and most importantly, 2) the directories belong to these vendors.  They use these directories to market their players and/or advertisements on their web sites.

What I was hoping to find is an open-sourced directory similar to ICECast.  ICECast is a good start but like Shoutcast, it only contains ICECast stations.  The ideal would a directory with a web presence similar to Shoutcast or ICECast where the community could search and update the directory.  In addition, a user/developer could download the some/all of the directory in a number of formats.  From a performance perspective, you can't beat a preformatted flat file.  Although a true database has its advantages, it might be overkill for a list of internet radio stations.

Thanks for your feedback.  I'll keep looking.

A while back I found a list of internet radio stations (>8,000 stations, tab delimited flat file) and the author gave credit to this forum and/or to Ian for the list.  I did a quick search and could not find any such list.

Does anyone know of any such list and where I can get me hands on it?  If not, does any know where I can download or subscribe to such a list?

Thank you for your assistance.

... I think the problem must be in how the tag structure is being processed. Are you using the TAG_ID3 structure to do that? If not, please give that a try (an example snippet can be found in the TAG_ID3 documentation).

It was definitely a programming error on my side.  I was using a function that was reading the ID3v1 tag as a single string and then breaking up the string into the individual fields.  Since the function worked on 99% of my MP3s, I incorrectly assumed that there might be as problem with the BASS_ChannelGetTags function.  It turns out the problem MP3 that I sent you was lousy with null characters within the ID3v1 tag and so my function only returned the first 18 characters.

Sorry 'bout that.  Thank you for your assistance and your support.

[tags.dll]

Can you clarify what sort of problem you're having with BASS_ChannelGetTags, eg. is it returning nothing (NULL) when you request ID3 tags, or is it just that the ID3 tags aren't in string form like the APE tags are? If it's returning nothing, are the same files fine with the TAGS add-on update? The TAGS add-on uses the BASS_ChannelGetTags function internally, so it would be impossible for the TAGS add-on to work properly if the BASS_ChannelGetTags function isn't

I'm not sure anymore.

First of all, I only assumed the problem encompassed ID3v2 but I never got around to coding for ID3v2 when I ran into the problem.  With the release of the updated tags.dll (thanks again), hopefully I never will.

The problem I'm experiencing appears to be limited to ID3v1.  In my example problem MP3, only the first 2 fields,  ID ("TAG") and Title, are available.  All other fields are blank/null.  In the example problem MP3, the only other field that was populated was the Artist, so to make sure I wasn't just seeing things, I manually (using the OS ("Properties" dialog)) added values to all of the other ID3v1 fields.  Problem persists.  Just in case you wanted to see this problem for yourself, I loaded GetTagExample02.mp3 to your ftp server.

But and however, the tags.dll add-on has no problem accessing this information.  If this add-on is internally using the BASS_ChannelGetTags function, then I must be doing something wrong but it does leave me confused.  I have no problem reading ID3v1 tags from other MP3s.

Bottom line: The tags.dll add-on is working well.  While researching this problem, I put it through the wringer by making all kinds of changes to the tag fields and adding and deleting tags.  The TAGS_Read function returned the correct information every time.  Since the tags.dll add-on is working well, this is definitely a non-issue for me.

Thank you for your assistance and support.

[BASS_ChannelGetTags]

... an updated TAGS build was posted fairly recently, which checks all available tag types for each requested item, eg. if it doesn't find a title in the APE tags, it will check the ID3 tags. You can get the update here...

   www.un4seen.com/stuff/tags.dll

Let me know if you still have any trouble with that.

The updated tags.dll does fix the problem.  Thank you.

The BASS_ChannelGetTags function (bass.dll) still does not return valid ID3v1 or ID3v2 data for these MP3s.  With the updated tags.dll, I'm good to go but I just wanted to let you know that the bug is still out there.

Once again, thanks for the fix.  I appreciate it!

[GetTagExample01.mp3]

Please do upload an example troublesome file to have a look at here...

   ftp.un4seen.com/incoming/

I haven't used FTP in many years.  It's been so long I couldn't figure out how to do it.  I finally resorted to using IE.  I "think" I got it working.  For some reason, I named the file GetTagExample01.mp3.

Thank you for your assistance.  Let me know if you can't find the file.

[TAGS_Read]

bass.ddl v2.4.8.1
tags.dll v0.0.16.0

The TAGS_Read function (tags.dll) and the BASS_ChannelGetTags function (bass.dll) do not return any usable ID3v1 or ID3v2 data under certain conditions.

I found the problem when I was creating a workout playlist for my brother who is training for half marathon.  By default, my collection of MP3s only have AP3v2 tags that are created when I run MP3Gain to "normalize" the volume.  Since my brother is using a iPhone to play his stuff, I figured that ID3 tags would be helpful so I added ID3v1 and ID3v2 tags with artist and title information.  I used Mp3tag to add the ID3 tags but the problem also occurs if you add the tags via the OS.  I'm using Window XP SP3.  BASS appears to have trouble reading the ID3 tags but other programs (I tried Winamp and Windows Media Player) have no trouble finding the ID3 information.

Problem synopsis: Tag functions do not work correctly on a MP3 where ID3v1 and ID3v2 tags are added to a MP3 that only has a AP3v2 tag.  In my test, I only added artist and title information.  If the ID3 tags are added to an MP3 that has no tags whatsoever, the tag functions work fine.

Thank you for your consideration.  If you are unable to duplicate the problem, I can make available one of my "problem" MP3s so that you can verify or refute the problem.

The debug version was sent yesterday, so you should already have it. If you don't see it, please check your spam folder in case it has ended up in there (quite common for Yahoo).

bkapusta, I have now sent the debug version to you too.

You were right.  This message was in the Yahoo Spam folder.  Please note that I've updated my profile with a new email address so hopefully, this problem won't happen in the future.

I performed the requested test per your instructions and I've sent you the resulting log file.

Thank you for your assistance.  Please let me know if you need any additional information.

[PM]

To take this further, I think I will have to send you a debug version to get some information on what is happening with the stream there. So that is what I will do.

Sounds like a plan.  When you are ready, just let know what you want to do.  If you want to take this offline, feel free to PM me.

Thank you for your assistance.

[1]

Here's a little modification to try...

   www.un4seen.com/stuff/bass.dll

Please let me know what difference (if any) it makes to the numbers and the stalling.

I tried the new DLL.  The results are virtually identical (within 20 packets).

I've done some additional testing and I think I may have some clues that might be helpful.  These clues are mostly based on observation and crude testing.  I'm not a network guy and the tools I do have are limited.

1. The first clue I've mentioned several times - download rate.  It takes more than 6 seconds for BASS to fill up the default 5 second buffer from this server.  Winamp needs just over 3 seconds to fill the same sized buffer.

My player has a progress meter that shows the buffer size while starting and when stalled.  I changed it to always show while playing an internet stream and as a result, I've discovered a few more clues.

2. As expected, the progress meter shows that the consumption rate is faster than the replenish rate.  The buffer will be a certain size (Ex: 80%), fall to 60%, jump back to up to 75%, fall down another 20% segment to 55%, jump back up another 15% segment to 70%, and so on until it flutters between 0% and 5% for a few seconds before it stalls.  While stalled, the buffer fills up to ~50% before playback resumes where the consumption/replenish cycle repeats until it stalls again.

3.  Out of curiosity, I hit Pause to watch the buffer fill up.  As soon as it filled to 100%, I resumed play to see what happens.  As expected, the buffer eventually emptied and playback stalled. See clue #2.  I tried this a few times and I noticed that if I wait a short period of time after the buffer is filled before resuming play, something totally unexpected occurs: the buffer stays full.  The meter shows the buffer jumping back and forth between 80% and 100%.  Sometimes the effect doesn't last and playback eventually stalls but most times playback never stalls.  While playing in this "buffer stays at 100%" mode, SmartSniff reports a higher 60 second data transfer size: 1,678 packets; 1,966,320 bytes.  I haven't figured out the optimal "delay before starting/resuming play" time but it's around 1 second.  BTW, I get same results with BASS v4.2.8.1.

Well, there you go. I hope this helps.  If you would like a copy of my BASS player (it's just a compiled script, prototype version) so that you can see what I'm seeing, tell me where to send/load it and I'll make sure you get a copy.

Thank you for your assistance.

[Are there any BASS experts that can help us with this one?]

Is there a setting to tell the stream how quickly to pull the data from [an internet server]?

I haven't found anything but I'm still a BASS newbie and haven't gone through every option yet.  Are there any BASS experts that can help us with this one?

[BASS]

If you inspect the network traffic (eg. using Ethereal), do you see anything different between when you use BASS and Winamp to play the stream?

I quit using Ethereal a while back because it kept crashing my computer.  I don't really have any networking monitoring tools except SmartSniff.  It's is a poor replacement for Ethereal but it's what I got.

After closing all programs that use the internet, I ran the BASS player for 60 seconds, Winamp for 60 seconds, and to add another BASS perspective, I also ran the latest version of XMPlay for 60 seconds.  These are the statistics:

BASS: 1,447 packets; 1,696,421 bytes
XMPlay: 1,336 packets; 1,567,797 bytes
Winamp: 1,847 packets; 2,163,550 bytes

As expected, BASS and XMPlay stalled several times during this test and Winamp never stalled.  Since the buffer sizes are the same, the Winamp statistic represents the approximate amount of data that is needed for this 1 minute test.

Also, does the problem only affect this particular stream/server, or is it happening with others too?

Although I'm sure that I can find other problematic servers (Hint: Look for low capacity servers with high quality (256+ kbps) streams, so far this is only one that I've run into that has this particular problem.  All of the other streams that I've used work fine with BASS.

Once again, thank you for interest and your feedback.  If you (or anyone!) can duplicate my results or if you have any ideas on how to resolve this problem, please post it!

Please also confirm the prebuffering settings that you are using with BASS and the Winamp MPEG plugin. The Winamp plugin's default appears to be to prebuffer 40%, while BASS_CONFIG_NET_PREBUF defaults to 75%, which could explain the different times taken to prebuffer. Also, following a buffer underrun, the Winamp plugin appears to prebuffer only 10% by default, while BASS currently always prebuffers 50% in that scenario. To see whether that is having a bearing, you could try setting the Winamp plugin to prebuffer 50% following buffer underruns too.

I was very careful to do an "apples to apples" comparison.  For BASS, pre-buffering (BASS_CONFIG_NET_PREBUF) is turned off.  Playback is not started until the entire buffer (BASS_CONFIG_NET_BUFFER) is full.  The default buffer for this stream is 160,000 bytes (~156K).  For Winamp, I set the buffer size to 157K.  The "streaming prebuffer" is set to 100% so that playback does not begin until the entire buffer is full.  The "prebuffer after a buffer underrun" is set to 60% but it is never triggered since the stream doesn't stall.

Thank you for your interest and your feedback.

That stream's bitrate is actually quite high at 256kb/s (I would consider low bandwidth to be more like 64kb/s). That's still well under your 3mb/s connection speed, but perhaps there is some congestion between the server and you that means the required transfer rate can't be sustained. That seems to be the case for me (here in the UK), as it is stalling in Winamp too when I try to play it. Are you sure the same URL never stalls in Winamp there? Perhaps you were actually playing a low bandwidth stream in Winamp rather than the one above?

Thank you for taking the time to respond.

I'm sorry for the confusion. What I meant by low-bandwidth is not the stream itself but the server's capacity. The stream's high 256kb/s bitrate just makes it easier to expose the problem.

Yes, there are are many conditions that can cause this problem - 1) limited client bandwidth, 2) network congestion/problems and 3) limited server bandwidth.  Yes, I too can get Winamp to stall if I overload the connection and then try to play the stream.

But and however, when all conditions are ideal (or satisfactory at least), BASS consistently stalls and Winamp never stalls.  I don't really mean never.  My tests last for 5 to 10 minutes.  I really wish you (or anyone) could duplicate the problem I'm having.  And no, I double checked.  Winamp is connecting to the exact same server and port that BASS is connecting to.

From a non-technical perspective, Winamp appears to be able to download faster from this server than BASS, at least with the current configuration.  To test this theory, I modified Winamp so that it has the same buffer size as BASS for this 256kb/s stream.  Like I mentioned in the 1st post, BASS takes more than 6 seconds to load it's entire default 5 second buffer.  Winamp is able to load the same size buffer in ~3 seconds.  At this load rate, the BASS player will always stall regardless of the buffer size and Winamp will never stall.

If you are able to duplicate my results and/or if you have any ideas on how to improve BASS's performance for this server, please post it!  Thank you for your feedback and assistance.

[XMPlay]

BASS v2.4.8.1
Windows XP SP3
Average internet connection (~3 Mbps)

I was able to duplicate this anomaly on the XMPlay and Trout players.

When connecting to a low-bandwidth server (I only have one example: http://72.13.83.87:9012), BASS cannot keep up.  Well, not on my PC anyway.  The stream is stalling every 20 to 40 seconds or so to refill the buffer.  In my independent tests, it takes more than 6 seconds to fill up a 5 second buffer which means that no matter how large the buffer is made, playback will eventually stall.

The weird thing is that if I play this exact same URL on Winamp, the stream never stalls.  Winamp has no problem handling the stream with a ~64K buffer while BASS struggles with a much larger buffer (default of ~156K for this stream).

Any ideas, suggestions, recommendations, etc. Thanks in advance for your assistance.