If you use Winamp and want your transmitted and streamed audio to sound professional but do not have the expensive processor (i.e., Innovonics) I strongly suggest the Stereo Tool Plugin by Hans van Zutphen available in a free version, or a more complete inexpensive version
http://www.stereotool.com/
I am mentioning the Stereo Tool for two reasons at this present moment, for one thing my radio signals have that full present sound which is a total pleasure to listen to all day and it’s because of the Stereo Tool. But the other reason this plugin is on my mind is because of a problem I’ve been having which I have theoretically traced to the Stereo Tool.
In another thread, asking for Shoutcast help, I have made several entries regarding the frequent disconnection and reconnection of my Shoutcast Server from the YP (Yellow Page Directory) at shoutcast.com.
One cause, I found through experimentation, is the conversion going on in real-time within Winamp as it converts the audiofile bit-rates to the streaming bit-rates. Winamp does this very well until some odd-ball file values show up and then it seems to appear like a “lost source.”
One audio file in particular causes the connection to drop and reconnect about once a minute during its 15-minute length. It is a Time-Counter that I use to fill time with clock-like pulses similar to WWV Time Radio. My theory is that the pulses happen BEFORE the Stereo Tool can hard-limit them, thus exceeding the headroom limit from the Shoutcast Server. With this in mind, it is possible that other disconnects may be happening from any audio material with a strong starting velocity.
If my theory holds up, all I need to do is drive my stream with a very careful top-end threshhold.
I will be back after manipulating things.
Something Else is Wrong
After running a couple hours of after-hours tests it appears the Stereo Tool Plugin has nothing to do with the Shoutcast Directory dropping that occurs when I run my Time Counting pulses that mimic WWV the time radio station. No matter what audio levels are used, this one file always causes a series of disconnections and reconnections which clear up after the file is finished.
Tomorrow I’ll post the mp3 so anyone who can help will study it and try to estimate why it would cause the connection with shoutcast to drop.
Should Be No Reason
There should not be any reason for that particular file to be causing a disconnect from the server. The mp3 file itself has nothing to do with maintaining connection between the actual stream encoder and the stream server.
But since you are experiencing this effect, obviously it means that something IS unusual about that mp3 file. It could be the meta data, it could be glitches in the mp3 stream data in the file itself, causing the connection to glitch.
My advice is to make a new mp3 file with the WWV “ticks” for the time purposes. I mean a real new mp3 file and not just a copy of the existing one. If it is a mere copy, the issues will copy over to the other mp3 file and the issue is also duplicated.
RFB
Reason Afterall
RFB said “The mp3 file itself has nothing to do with maintaining connection between the actual stream encoder and the stream server.”
Actually the mp3 file is part of generating the stream format, which is done while the file plays through the DSP Encoder Plugin, and the shoutcast YP is sensitive to “source,” which is the stream signal.
By hitting STOP and sending no audio, the source is gone and the shoutcast YP disconnects.
My troublesome file either makes the shoutcast YP think there is no source, or it is somehow knocking the source out of step in some way.
But it does strongly suggest that an mp3 file can trigger a disconnection.
Late last night I remade the file in several different ways and it disconnects the shoutcast connection 100% of the time. The time pulse audiofile I am talking about has been generated by an Audacity special effect feature called “Clik Trak.” It seems to have a bug.
More About That
The Shoutcast DSP Source Plugin has a CONNECT button which sends the MP3 files being played in Winamp to the Shoutcast Server. The Source Plugin has a byte meter which shows the stream action in micro-second increments. When this connection is established the Server reaches out and connects to the Shoutcast.com Directory.
The constant MP3 playback from Winamp keeps the DSP Plugin byte meter running. If the STOP button on Winamp is pressed, the MP3 audio stops, the DSP Source Plugin senses no source and the “no source” condition causes the Server to disconnect from the Shoutcast Directory.
Therefore the MP3 audio files play a crucial role in maintaining a connection. The fact that I have an MP3 file that disconnects the system 100% of the time proves that certain, as yet unknown, MP3 audiofile qualities can and do cause a system disconnect, EVEN WHILE THE MP3 FILE CONTINUES TO PLAY AND GENERATE AUDIO.
Wrong
No the mp3 file has nothing to do with the stream itself. The mp3 file is nothing more than a source. Trust me Ive been doing net streaming since 1996.
Now here is what is most likely happening.
You have the DSP plug in encoder set for direct data input from the systems sound card processor. If that mp3 file has any sort of data glitch in it, those glitches will pass through the sound card processing and right into the encoder and the encoder is merely doing its job..passing along the data on to the server.
So back to my original diagnosis. That mp3 file has a weird problem within itself. So replacing this file with a new one should resolve the problem.
Another area to look at is the audio processor dsp plug in. The particular processor plug in..”Stereo Tool” is a good one. I have the very same thing on my production pc and automation pc. Let me ask…what “quality” level do you have that set for and screen refresh time set for?
Cuz if you have both set too high, that chews up so much CPU power that not only could it cause an encoder to server drop out issue, but also lock down your CPU data buss at regular intervals as the CPU approaches 100 percent utilization. You can monitor this through the task manager performance meter.
All software processing programs and plug in’s use a ton of CPU processing power and memory resources. If you aint got the horse power, expect problems. So you have to tone down those processor a bit to conserve the CPU and memory resources.
You may be dealing with putting too much weight on the horse and it is simply bogging down.
But dont take my word for it. Go to the shoutcast forum and see for yourself how too little badaboom and too much badabing will put your entire wagon to a screeching hault.
Want to solve this the quick and dirty way…change the dsp’s source from direct sound card to line in. Then load nothing into the winamp play list and have the encoder connect to the server. Watch in awe as the encoder with no input data keeps its connection to the server….why?…simple..because the encoder is now relying on the sound card direct line input and the sound card is always outputting data even if there is nothing going into it, hence the encoder and server see data regardless if audio is there or not.
So to conclude, the mp3 file has nothing to do with the encoder and server maintaining connection unless you have that encoder set for direct data input..which if you want to know the truth, is NOT the correct way to be streaming. If you want details as to why, just ask.
RFB
Digging Deeper
Good comments, RFB, the Shoutcast DSP Encoder is set for WINAMP INPUT (recommended). I think that means that the source information comes from the MP3 files and there must be one running or the source is gone.
The other input, LINE IN (Legacy Mode) is something I haven’t tried. You have explained how it is different, and that also is an inpu method that makes it possible to “speak live” directly on the stream from the outboard audio mixer. The downside of that is, if I leave the mic open my private conversations will be heard by listeners in Guatamala.
I expect the LINE IN will solve this situation, but I still wonder how it would be possible to do an autopsy on the errant mp3 file so as to understand what’s bad with it….
This disconnection happens with Stereo Tool bypassed, so I no longer suspect the processor of being part of the problem. The CPU Quality setting is 3/4 of the way up, toward High, but not all the way up. The CPU Usage is between 5% and 15% with the stream running.
Inspecting The MP3 File
Best way is to load that mp3 file into an audio editor, one that will let you expand the displayed waveform. Slowly scan the entire mp3 file waveform and look for gaps, or any spike waveforms that are not normal to the rest of the waveform.
What has me curious is even if there are gaps or spikes within the waveform, they should not be of any significant duration length that would cause a “time-out” between the encoder and server.
What also is curious is how do you synchronize this mp3 file containing time pulses to the real world clock for accurate time signals and account for the internet streaming delay factors..and even more curious…why run an mp3 file of time pulses on the station, I mean what purpose is it serving other than causing this drop out issue?
If it were me, I would simply tie in a SW radio and re-transmit the WWV audio. At least those time pulses will be direct from the atomic clock and far more accurate.
RFB
The Time Counter mp3 FILE
I have inspected this file using Audacity, but found no clues why it would disconnect with the shoutcast connection continuously during playback… I hope you will inspect it and report what you find.
http://www.kdxradio.com/am-files/COUNTDOWN_15m.mp3
Bad link Carl
Bad link Carl
Brain Drain
Thank you Rich Powers for letting me know the link was broken. I spent 15-minutes here messing with it just now trying to figure out what was wrong. But computers are so dumb… they refuse to fix my mistakes, but they also won’t tell me what the mistake is. Grrr!
This link should work, knock on head, or wood, as the case may be
http://www.kdxradio.com/am_files/COUNTDOWN_15m.mp3
The Debate Isn’t Over
RFB wrote “The mp3 file itself has nothing to do with maintaining connection between the actual stream encoder and the stream server.”
Actually that’s not true, also it’s not exactly on point. My point is that connection with the shoutcast.com YP (Directory) becomes disconnected. The server, which runs from my computer, keeps running just fine UNLESS THE MP3 PLAYBACK IS STOPPED.
The mp3 file being played within Winamp DOES have a direct affect on the connection with the shoutcast directory.
My Time Counter file ALWAYS causes a disconnect. Another example of a show that disconnects me from the directory everyday is Free Talk Live, the talk show from Keane, NH.
Free talk live is an mp3 file at 48kbps / 32kHz sample rate.
In this streaming system, which consists of a string of software inter-connections as follows…. mp3 file plays in Winamp / get converted to streaming format in Shoutcast DSP Plugin / trigger the Shoutcast Server to run, which connects to / shoutcast YP Directory, which / sends back signals to the server acknowledging connection or disconnection.
Simply stopping the mp3 playback WILL TRIGGER THE SERVER TO STALL and A DISCONNECTION WITH THE SERVER. Therefore the mp3 file DOES have a direct affect on the server. The statement – “The mp3 file itself has nothing to do with maintaining connection between the actual stream encoder and the stream server.” – is invalidated.
ALSO, the start of an mp3 file playback sends title information across the connection which gets listed on the Shoutcast Directory. This information only gets transmitted at the very start of the mp3 playback, so if connection with the directory is made during an already playing audio file, Shoutcast Directory might reply “Error updating station information” or “Internal error – Unable to acquire data.”
I have found in the case of the Free Talk Live mp3 file it is the re-conversion between 32kHz and 22.05kHz is what causes a disconnection. Everyday I need to re-sample the Free Talk Live mp3 and change the rate to either 44.1kHz or 22.05kHz, both of which pass through the system without causing a disconnection.
But I still do not know why this one specific file ALWAYS drops the Directory connection
http://kdxradio.com/am_files/COUNTDOWN_15m.mp3