Who is that directed to and what's your point? If that's directed to me, it doesn't apply. The link talks about file in/out which not using and the options shown are not recognizable so I'm sure not using this method,
Improve Broadcastify Feed Quality?
- Thread starter AggieCon
- Start date
- Status
Who is that directed to and what's your point? If that's directed to me, it doesn't apply. The link talks about file in/out which not using and the options shown are not recognizable so I'm sure not using this method,
Howdy Proscan,
Thanks for the links to your feeds. I've been listening to a lot of material, so hence my replies spaced out over time. My previous post was just something I came across while working on a project, and, since it is another's viewpoint of what I'm discussing, I wanted to add it to the thread. I'm not promoting his exact settings, just the idea of lower sample rate when using low bitrate, especially when it's just voice.
There is no doubt to me with my studio headphones on that your direct (8 kHz) feed is much better quality than the Broadcastify stream. Even at such a low bitrate, your 8 kHz stream is pleasant to listen to. The Broadcastify version has substantially more artifact, including a whistling noise that'll give me a headache in a hurry. I assume I accessed your other feed locally from your computer and that you are broadcasting it using the server feature of your software? Your Broadcastify feed has substantially less gain than your other feed, by the way. I had to ~triple the amplitude to make the two feeds similar in volume.
Regarding the "delay", the Radio Reference feed is just under 10 seconds behind your local feed, at least as it hits my speakers.
Your software is awesome, by the way. Have you experimented with average or variable bitrate, or any other codecs like Opus?
I setup an encoder with my scanner on line in yesterday, and using a variable bit rate, the average file sizes are just a little above 8 kbps (the minimum rate used for absolute silence). Yet the audio quality is more than acceptable. If I increase the file size to around 30 kbps, the quality is amazing. So if bandwidth is the factor, there's certainly methods to both improve quality and reduce data demand, all at the same time. It just doesn't make sense to me to waste bandwidth for silence.
Here's a feed I found that I was particularly impressed with: Charles County Sheriff Dispatch - D1/ D3
Thanks for contributing to the thread.
Justin
Thanks for the links to your feeds. I've been listening to a lot of material, so hence my replies spaced out over time. My previous post was just something I came across while working on a project, and, since it is another's viewpoint of what I'm discussing, I wanted to add it to the thread. I'm not promoting his exact settings, just the idea of lower sample rate when using low bitrate, especially when it's just voice.
There is no doubt to me with my studio headphones on that your direct (8 kHz) feed is much better quality than the Broadcastify stream. Even at such a low bitrate, your 8 kHz stream is pleasant to listen to. The Broadcastify version has substantially more artifact, including a whistling noise that'll give me a headache in a hurry. I assume I accessed your other feed locally from your computer and that you are broadcasting it using the server feature of your software? Your Broadcastify feed has substantially less gain than your other feed, by the way. I had to ~triple the amplitude to make the two feeds similar in volume.
Regarding the "delay", the Radio Reference feed is just under 10 seconds behind your local feed, at least as it hits my speakers.
Your software is awesome, by the way. Have you experimented with average or variable bitrate, or any other codecs like Opus?
I setup an encoder with my scanner on line in yesterday, and using a variable bit rate, the average file sizes are just a little above 8 kbps (the minimum rate used for absolute silence). Yet the audio quality is more than acceptable. If I increase the file size to around 30 kbps, the quality is amazing. So if bandwidth is the factor, there's certainly methods to both improve quality and reduce data demand, all at the same time. It just doesn't make sense to me to waste bandwidth for silence.
Here's a feed I found that I was particularly impressed with: Charles County Sheriff Dispatch - D1/ D3
Thanks for contributing to the thread.
Justin
Hi AggieCon
I never really looked into Opus before. Preliminary research so far but looks very promising. I will definitely be experimenting with it in the next few months trying various sample rates, bitrates, frame duration, constant/variable bitrate, etc. I may use it in the RSOIP, Source Client, and Web Server features.
On my Broadcastify feed, I'm not noticing any artifact or volume differences on both feeds. Both feeds are from the same source. The Source Client feature is streaming to Broadcastify and the Web Server streams to any media player connected.
I never really looked into Opus before. Preliminary research so far but looks very promising. I will definitely be experimenting with it in the next few months trying various sample rates, bitrates, frame duration, constant/variable bitrate, etc. I may use it in the RSOIP, Source Client, and Web Server features.
On my Broadcastify feed, I'm not noticing any artifact or volume differences on both feeds. Both feeds are from the same source. The Source Client feature is streaming to Broadcastify and the Web Server streams to any media player connected.
Update re ProScan's feeds
ProScan, I messed that up! Sorry about that. There is not a huge difference in volume between your two feeds. I was using two computers, routed through Virtual Audio Cable and into Audacity. I guess some level setting was not consistent. I just obtained a better set of samples for comparison using some FFmpeg script.
As in my analysis from a few days ago, the feed with the higher sample rate is slightly louder on average. However, the soft parts (background "noise") is relatively louder than the foreground -- the speech. In the first sample I used, the 22 kHZ radio reference feed had foreground and background levels of -19.3 dB and -47.5 dB, respectively, which is a difference of 28.2 dB. The local feed of 8 kHz tested -19.4 dB foreground and -47.8 background, which is a difference of 28.4 dB. In some of the additional samples, the decrease in background level of the 8 kHz feed was even more significant, leading to a foreground-background spread of 3-4 dBs in favor of the 8 kHz feed.
I was able to amplify the 8 kHz a bit more without clipping, meaning if amplified to the point just before distortion, the 8 kHz is going to provide more dynamic sound, making the speech easier to understand, especially on more marginal feeds (comparing your contrast values with Glenn's, you can tell that your feed is easier on the listener, likely because of your digital transmission of the radio traffic). Overall, there were more annoying pops and clicks in the 22 kHz feed. Note... in the tests above, they were at their baseline level.
The 22 kHz feed has a whistling noise, like wind rushing by almost, as well as other artifacts, clicks, and pops, making it a bit more scratchier. The artifacts are more easily recognized during times without voice (because we like to mentally focus on voice). This is present throughout, though. The following clip is an exaggerated sample of the same set of background noise to attempt to demonstrate what I am hearing throughout. The first few seconds is the 22 kHz RR fee, the next is from the 8 kHz fee, then the 22 kHz follows again, and last, the two alternate fairly rapidly. The regularly spaced "clicks" are where I spliced the audio together. On the 8 kHz version, you hear the nice rumble of low speed data without artifact, which will put you to sleep almost as fast as a diesel engine.
22 kHz vs 8 kHz Sample Rate Background Noise Comparison
Below is another sample, this time with voice. I won't spoil the order in this one.
Radio Reference vs Local Feed Comparison
And here's a comparison of the frequency spectrums:
I think Opus would be an awesome addition to your product. I am going start working on compatibility tests of the codec using my own server. It doesn't look like I'll achieve a Broadcastify slot to test things out. Once I get some streams up to test, I'll try to spread the word to have others test them with as many devices, browsers, and players as possible. I think that'll help you judge whether it is worth implementing.
ProScan, I messed that up! Sorry about that. There is not a huge difference in volume between your two feeds. I was using two computers, routed through Virtual Audio Cable and into Audacity. I guess some level setting was not consistent. I just obtained a better set of samples for comparison using some FFmpeg script.
As in my analysis from a few days ago, the feed with the higher sample rate is slightly louder on average. However, the soft parts (background "noise") is relatively louder than the foreground -- the speech. In the first sample I used, the 22 kHZ radio reference feed had foreground and background levels of -19.3 dB and -47.5 dB, respectively, which is a difference of 28.2 dB. The local feed of 8 kHz tested -19.4 dB foreground and -47.8 background, which is a difference of 28.4 dB. In some of the additional samples, the decrease in background level of the 8 kHz feed was even more significant, leading to a foreground-background spread of 3-4 dBs in favor of the 8 kHz feed.
I was able to amplify the 8 kHz a bit more without clipping, meaning if amplified to the point just before distortion, the 8 kHz is going to provide more dynamic sound, making the speech easier to understand, especially on more marginal feeds (comparing your contrast values with Glenn's, you can tell that your feed is easier on the listener, likely because of your digital transmission of the radio traffic). Overall, there were more annoying pops and clicks in the 22 kHz feed. Note... in the tests above, they were at their baseline level.
The 22 kHz feed has a whistling noise, like wind rushing by almost, as well as other artifacts, clicks, and pops, making it a bit more scratchier. The artifacts are more easily recognized during times without voice (because we like to mentally focus on voice). This is present throughout, though. The following clip is an exaggerated sample of the same set of background noise to attempt to demonstrate what I am hearing throughout. The first few seconds is the 22 kHz RR fee, the next is from the 8 kHz fee, then the 22 kHz follows again, and last, the two alternate fairly rapidly. The regularly spaced "clicks" are where I spliced the audio together. On the 8 kHz version, you hear the nice rumble of low speed data without artifact, which will put you to sleep almost as fast as a diesel engine.
22 kHz vs 8 kHz Sample Rate Background Noise Comparison
Below is another sample, this time with voice. I won't spoil the order in this one.
Radio Reference vs Local Feed Comparison
And here's a comparison of the frequency spectrums:
I think Opus would be an awesome addition to your product. I am going start working on compatibility tests of the codec using my own server. It doesn't look like I'll achieve a Broadcastify slot to test things out. Once I get some streams up to test, I'll try to spread the word to have others test them with as many devices, browsers, and players as possible. I think that'll help you judge whether it is worth implementing.
hatchetation
Newbie
- Joined
- Sep 19, 2015
- Messages
- 2
Aggiecon,
I had a really long reply written in violent agreement with lots of supporting details, but the forum software decided to save you all from it.
In short, we've reached a lot of the same conclusions:
1) 8kHz sampling is working fantastically here. If you know Nyquist and you know narrowband, I'm not sure there's much of an argument to be had.
2) Unless Broadcastify reconsiders their no-delay policy, they're leaving SDR out in the cold. I reached the *exact* same queueing solution as you - because I'm capturing a busy system with 4-5x what I can play in realtime. But more fundamentally, any software system which is building up a stateful representation of individual calls is incompatible with Broadcastify's worldview.
By dealing with a quanta of individual calls, I can post-process to cut their length significantly through tight head/tail elimination, can archive them, can adjust gain over an entire clip, can collate them by talkgroup, &c ...
They seem to assume you have a Uniden on an umbilical cord somewhere. To the contrary, I have a system which can capture 30 simultaneous conversations at once, and dynamically create streams based on queries like this:
"tags
police) AND NOT tagsfire OR transit OR jail OR corrections OR dispatch OR data OR burbs or uw)"
If Broadcastify came up with a concrete policy like, "don't play anything over a minute old, don't reverse time, keep jitter within 20 seconds" I could offer dozens of dedicated streams, including streams for low-volume topics like search & rescue.
Until then, I guess these streams get to stay with friends & family, and we'll enjoy the tactical channels too.
I had a really long reply written in violent agreement with lots of supporting details, but the forum software decided to save you all from it.
In short, we've reached a lot of the same conclusions:
1) 8kHz sampling is working fantastically here. If you know Nyquist and you know narrowband, I'm not sure there's much of an argument to be had.
2) Unless Broadcastify reconsiders their no-delay policy, they're leaving SDR out in the cold. I reached the *exact* same queueing solution as you - because I'm capturing a busy system with 4-5x what I can play in realtime. But more fundamentally, any software system which is building up a stateful representation of individual calls is incompatible with Broadcastify's worldview.
By dealing with a quanta of individual calls, I can post-process to cut their length significantly through tight head/tail elimination, can archive them, can adjust gain over an entire clip, can collate them by talkgroup, &c ...
They seem to assume you have a Uniden on an umbilical cord somewhere. To the contrary, I have a system which can capture 30 simultaneous conversations at once, and dynamically create streams based on queries like this:
"tags
police) AND NOT tagsfire OR transit OR jail OR corrections OR dispatch OR data OR burbs or uw)"If Broadcastify came up with a concrete policy like, "don't play anything over a minute old, don't reverse time, keep jitter within 20 seconds" I could offer dozens of dedicated streams, including streams for low-volume topics like search & rescue.
Until then, I guess these streams get to stay with friends & family, and we'll enjoy the tactical channels too.
Hatchetation,
I think we are along the same lines of thinking. I should enjoy hearing about your setup. Email me or let's start a new thread about it. A link to my email should be found by clicking on my screen name. If that doesn't work, let me know. It won't let me message you.
I think we are along the same lines of thinking. I should enjoy hearing about your setup. Email me or let's start a new thread about it. A link to my email should be found by clicking on my screen name. If that doesn't work, let me know. It won't let me message you.
We don't have a blanket policy in place that says you can't stream an SDR solution.
We simply don't allow predefined purposely implemented delays in streams unless they are officially provided streams.
If you guys want to contact me offline to review how we might integrate some of these solutions, I'm all ears.
Aggiecon, sorry I haven't gotten back with you. I'd be more than happy to setup some test private feeds on our servers so you can run your tests further on our infrastructure. Contact me offline at lindsay [at] radioreference.com
Thanks,
We've been doing 0-4 kHz and 8 kHz sample rate audio since the original SoundBlaster; .VOC files, not .WAV files carried the uncompressed audio. If you want to stream at 22 KHz, then do transcoding at the streaming media server, not the broadcast feed. There is just no reason to run the sample rate that high when there is literally no information there to be heard and the extra bits wasted. Post-narrowbanding, emission mask assures there is no audio above the roll-off, period. Using a codec such as Speex, one can approach 4 kbit/s for a single stream of 0-4 kHz of audio at an 8 kHz sample rate. At best case, one can stream three distinct streams given two channels: Hard Left, Center, and Hard Right. That provides a better utilization for stereo feeds. However, sometimes ATC has the radios tied together and you'll will observe audio effects as a result.
bctrainers
Member
Has AAC been considered for the broadcastify feeds? I am unsure the backend for the streams, but i assume a flavor of icecast?
https://en.wikipedia.org/wiki/Advanced_Audio_Coding and http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#Bitrate_Modes
AAC in general can provide good to great quality at low bandwidth costs.
https://en.wikipedia.org/wiki/Advanced_Audio_Coding and http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#Bitrate_Modes
AAC in general can provide good to great quality at low bandwidth costs.
- Status
Similar threads
