Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: shoutcast server & foo_vorbisstream-1.1_fix (Read 6243 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

shoutcast server & foo_vorbisstream-1.1_fix

Hello,

I've tried installing:

foo_vorbisstream-1.1          as well as
foo_vorbisstream-1.1_fix

Also tried putting lame.exe, lame_enc.dll, lamedll.dll in foobar's directory even though this has not been documented as a requirement. In fact I cannot find any documentation for this plugin.

The result is that a connection is made to the shoutcast server, even yp are updated when I hit play but no music is streamed.

If the configured shoutcast URL is called in another foobar (on a different pc) it shows:

Code: [Select]
Playback error
Unable to open item for playback (Unsupported format or corrupted file) : "http://bistro.fm:9000/"


In MPC-HC
Code: [Select]
Failed to render the file


Winamp just remains silent.

::

I should perhaps mention that I have 2 other active plug-ins in foobar:
- UPnP/DLNA Renderer    and
- Crossfader

Crossfading and Shoutcast doesn't do well in Winamp for instance,
but I'm not sure if that's the problem here in foobar as well.

::

edcast / oddcast / icecast ist not an option for me.

::

I would really like foobar to be able to stream to a shoutcast server.

Any help appreciated.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #1
By definition, the Vorbis Stream component is designed only for streaming Ogg Vorbis to an Icecast server. Support for MP3 or other formats may be added in the future, in which case it should be renamed to something else.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #2
Hi Kode54,

By definition

http://www.foobar2000.org/components

described the plugin as follows:

Vorbis Streamer 1.1, Tags: DSP, network, streaming, Vorbis
2009-11-18 Streams Vorbis and associated metadata to Icecast2 and Shoutcast servers.

The GUI does indeed have a shoutcast pulldown (see image):



::

But ok, if you are correct then it looks like I can ditch the plugin then.

::

Any other ideas on how to stream foobar to shoutcast welcome.

...No StereoMix, WhatYouHear, via Soundcard Output and Winamp solutions please.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #3
http://forums.winamp.com/showthread.php?t=147078 - Shoutcast does not support Vorbis. I should kill that dropbox. Mea culpa, I assumed edcast knew what it was doing with regards to this. I should have known better... Thanks for reporting. I'll merge this thread in with the main foo_vorbisstream thread probably tomorrow or something after you've read this.

It's bloody well about time for foo_vorbisstream v1.2 anyhow.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #4
Just a little extra comment… don't really assume that I know what I'm talking about here, but I would also like to (if possible) get the equivalent of a Shoutcast/streaming server working one day. I recall setting up Shoutcast many times back when I used to use the W… ugh.  The other player that Null… ugh.  Sorry, I'm like foobar2000 FTW since I started using it years ago.  Anyways, I didn't even use a relay server, since I was just streaming to a few people and my local upstream handled them fine. Since then, my admittedly half-hearted and unprepared attempts at streaming from foobar have been fruitless.

Is your intent to expressly serve content to peers over a WAN, or LAN? I ask because I've seen the other similar type plugin called uPnP/DLNA server, which I briefly tried and had no results with (but gave up quickly as PS3 Media Server had already proved working and served my needs); I just wanted to see if I could rid myself of yet another "server" application, replace it with a DLL in foobar which I already keep open. The failure was very likely the result of my impatience and confusion with the 3 different "modules" that worked together, not the component itself; so my message is, have you tried the plugin that I spoke of? If I recall it had http streaming capabilities, though don't take that as gospel— but it's easy enough to test and uninstall if it doesn't do what you need.

If you specifically require the use of a relay server for your broadcast, then I'm not sure how that would jive.

If you find out how to stream to remote clients over WAN/Internet I'd be interested to know your method. Format is not as important to me. Probably ideally I'd just use low bit rate MP3 for compatibility sake.

I need to look into this topic further anyway. It's been one of those "meaning to do that" things for a long time.

I know this is irrelevant but Mac OS X Server has built in faculties to stream their audio/video formats; but no idea about open source library integration.

Hope I contributed at least a thought, I know that was likely of no help. Sorry, mate. Wish I knew more for you.

Oh, one thing I did intend to bring up; you spoke of lame.exe; which I don't see the commonality with OGG/vorbis, but there is an area under the last section in the preferences; in Advanced where you are allowed to define specific paths for any external encoders; you will see it in the list near the top— have you tried adding your encoders paths here so it knows where to find them? I personally have a "Codecs" subdir under foobar with MP3, AAC, FLAC etc folders for each encoders files. Then my paths are set up in that field I spoken of in the preferences dialog. You tried this?

shoutcast server & foo_vorbisstream-1.1_fix

Reply #5
Hi Chinch,

Are you suggesting that putting the path to lame below will influence the Vorbis Streamer 1.1 plugin?      kode24 what do you reckon?

Preferences
- Advanced
- - Tools
- - - Converter
- - - - Additional command-line encoder paths

::

In response to your text...

Yes we are a licensed webradio, our intent is to serve content over the WAN to everyone. We have our own shoutcast relay servers.

I have UPnP installed, it's great - lets you remote control foobar using the Linn Kinsky app. If foobar could stream to shoutcast it would mean we could remote contol bistro.fm radio station from anywhere via mobile phone. As it stands we use RDP and SAM Broadcaster but this solution, even though one of the few that ensures quality, is a little too bulky, and kinda old fashioned.

Alternatively, we could use SAMCast in combination with foobar, but not only would that set us back $199, it also uses the sound card rather than direct input, meaning it'll broadcast everything not just what foobar is playing.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #6
Hi Chinch,

Are you suggesting that putting the path to lame below will influence the Vorbis Streamer 1.1 plugin?      kode24 what do you reckon?


Great detailed info. That helps out a lot (to everyone that may read and want to help). As far as the LAME encoder path influencing the Vorbis Streamer, no; that's why I originally said I don't understand LAME's role in the process, unless you were transcoding from MP3 to OGG or vice versa... it would still be good to have that info about what is your internal format, what you're wanting to broadcast to the relay servers, even as much as bitrates, etc. Obviously LAME doesn't do anything with OGG/Vorbis files, but FLAC.exe would, using this switch:

--ogg                When encoding, generate Ogg FLAC output instead
                        of native FLAC.  Ogg FLAC streams are FLAC
                        streams wrapped in an Ogg transport layer.  The
                        resulting file should have an '.oga' extension
                        and will still be decodable by flac.  When
                        decoding, force the input to be treated as
                        Ogg FLAC.  This is useful when piping input
                        from stdin or when the filename does not end in
                        '.oga' or '.ogg'.

I've never used any other encoder like anything from Xiph foundation, so I will be honest and say that the OGG or Vorbis format that you'd stream, I'm not really familiar with... but anything you use to encode or decode, transcode... I would at least be sure to test adding the full path to the option you mentioned. With my limited knowledge, I don't see a problem with using that FLAC encoder/decoder to take something from MP3 to a streamable container format like that... just use a bit of piping or command line juju to get it done, but certainly not impossible. Any more detail you can give me on the formats and anything else? kode24 is gonna be far more helpful than I am whenever you get a response there, but I'm just trying to help whatever I can in the meantime....

shoutcast server & foo_vorbisstream-1.1_fix

Reply #7
Hi Chinch,

Nothing as complicated as that.

http://bistro.fm files are all mp3s ranging from 128 to 320kbps and we broadcast in mp3 currently at 160kbps.

Lossless formats are simply not yet practical from a storage point of view and transcoding an already compressed and compromised format into another (e.g. from mp3 into aac) doesn't sound like a good idea.



Great detailed info. That helps out a lot (to everyone that may read and want to help). As far as the LAME encoder path influencing the Vorbis Streamer, no; that's why I originally said I don't understand LAME's role in the process, unless you were transcoding from MP3 to OGG or vice versa... it would still be good to have that info about what is your internal format, what you're wanting to broadcast to the relay servers, even as much as bitrates, etc. Obviously LAME doesn't do anything with OGG/Vorbis files, but FLAC.exe would, using this switch:

--ogg                When encoding, generate Ogg FLAC output instead
                        of native FLAC.  Ogg FLAC streams are FLAC
                        streams wrapped in an Ogg transport layer.  The
                        resulting file should have an '.oga' extension
                        and will still be decodable by flac.  When
                        decoding, force the input to be treated as
                        Ogg FLAC.  This is useful when piping input
                        from stdin or when the filename does not end in
                        '.oga' or '.ogg'.

I've never used any other encoder like anything from Xiph foundation, so I will be honest and say that the OGG or Vorbis format that you'd stream, I'm not really familiar with... but anything you use to encode or decode, transcode... I would at least be sure to test adding the full path to the option you mentioned. With my limited knowledge, I don't see a problem with using that FLAC encoder/decoder to take something from MP3 to a streamable container format like that... just use a bit of piping or command line juju to get it done, but certainly not impossible. Any more detail you can give me on the formats and anything else? kode24 is gonna be far more helpful than I am whenever you get a response there, but I'm just trying to help whatever I can in the meantime....


shoutcast server & foo_vorbisstream-1.1_fix

Reply #8
The result is that a connection is made to the shoutcast server, even yp are updated when I hit play but no music is streamed.
...
Winamp just remains silent.

that's most likely from it not being able to pass the stream data onto the correct plug-in (since it's basically assumed that SHOUTcast is MP3 or an AAC).

Crossfading and Shoutcast doesn't do well in Winamp for instance,
but I'm not sure if that's the problem here in foobar as well.

that's because the crossfading is done on the output in most cases and not on the audio which the Source DSP grabs.

I would really like foobar to be able to stream to a shoutcast server.

this i know will likely swing things off topic but i thought i'd add it in whilst it's vaguely related to the conversation in this thread.
currently only MP3 and AAC variants are the officially support SHOUTcast formats, however that does not say that it is not possible to to use SHOUTcast with other formats e.g. people are still using it to stream nsv streams.

the main issues with SHOUTcast + Ogg Vorbis support come down to a) player support in not being able to cope with things due to certain assumptions (i know it shouldn't happen but it does), b) decisions i don't really know about which mean it is not something to be viably considered being officially supported at least with regards to Directory listings and c) is there really the demand out there which would warrant the time to implement things as i've only seen a few hundred Ogg Vorbis streams listed on the Icecast Directory.


that is not to say that at least whilst i'm working on the SHOUTcast tools that i don't see it being something which could be useful (on a number of areas) to get some sort of implementation in place for SHOUTcast + Ogg Vorbis streams even if it were to be done as a side-project off my own-back in my freetime (which i vaguely remember having once ) since there is already provision for Ogg Vorbis in the SHOUTcast 2.0 protocol specifications and i've briefly looked into what would be needed to resolve point a) at least on the other player that is evil and shall not be named  and from a tools implementation which actually is pretty small since the DNAS at least will basically just push things through - it's mainly player support that the issue falls on (and ignoring the Directory aspect) as most source software should be simple enough to change if they already do it say for Icecast output anyway. but if it only is something potentially a few hundred streams might use, can i really warrant the time needed to work on such things... that i'm really not sure about at all.

-daz

 

shoutcast server & foo_vorbisstream-1.1_fix

Reply #9
Hi DoctorO

Quote
not being able to pass the stream data onto the correct plug-in
sounds like a possible explanation, so why is that? I don't understand the text you wrote in brackets...
All our files are indeed mp3s and we also want to broadcast in mp3 format.

The result is that a connection is made to the shoutcast server, even yp are updated when I hit play but no music is streamed.

that's most likely from it not being able to pass the stream data onto the correct plug-in (since it's basically assumed that SHOUTcast is MP3 or an AAC).


As for "demand" ... how many webradio broadcasters are there? Compared to users not so many - but it may gain quick popularity with those few that are currently stuck with commercial stuff like sam broadcaster, especially if they notice foobar can be remote controlled from a phone.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #10
As a developer, the Shoutcast metadata format is atrocious. Winamp was far and away a superior Nullsoft product when compared to Shoutcast. Speaking honestly, Winamp is a pretty great program, despite my preference for foobar2000.

Please don't ruin good Vorbis streams with Shoutcast metadata.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #11
sounds like a possible explanation, so why is that?

because it's just how Winamp's input plug-in system works as the SHOUTcast streams basically go through in_mp3.dll and since Ogg Vorbis is not handled in that input plug-in it currently isn't handed off to in_vorbis.dll (though having .ogg on the stream url would alleviate some of that but based on what i've seen over the last year a lot of people never properly configure their DNAS server's correctly to do such things).

I don't understand the text you wrote in brackets...

what i meant is that from a SHOUTcast view point, MP3 and AAC variants are the only output format that will currently be provided to clients if the station is listed in the Directory. it's never limited the format of the input media used as long as the source software being used is able to convert it to the supported formats. hopefully that clarifies what i was trying to say.

As for "demand" ... how many webradio broadcasters are there? Compared to users not so many - but it may gain quick popularity with those few that are currently stuck with commercial stuff like sam broadcaster, especially if they notice foobar can be remote controlled from a phone.

that's a fair point and is why i'm a bit torn as it's a bit of a chicken+egg scenario. maybe it would gain popularity though if looking at what is already out in a comparable setup only has a few hundred stations using it, that makes me somewhat hesitant about trying to find time to look into implementing things towards it.


As a developer, the Shoutcast metadata format is atrocious. Winamp was far and away a superior Nullsoft product when compared to Shoutcast.
...
Please don't ruin good Vorbis streams with Shoutcast metadata.

i assume you mean the StreamTitle=xxx insertion? if so then there's not much which can be done about it if people use a v1 based DNAS or a v1 only client as that cannot be changed. if using a v2 DNAS and v2 compatible client then the metadata comes through in it's own 'metadata' packet type which is xml inside it so it's a lot more flexible over the v1 method though maybe xml wasn't a great idea since it's larger than it necessarily should be (but that's now something which is inplace so there's not too much which can be done to change it). there's more details about the specification and xml-based metadata here.

-daz

shoutcast server & foo_vorbisstream-1.1_fix

Reply #12
Ah, good. I see help has arrived. I was posting this info for another thread and I immediately thought of you, and wanted to offer the links if you don't have them already just for knowledge.

I know this is surely in the FAQ's/board docs somewhere, but just a short, quick reminder that if you want/need FLAC support outside of something like foobar2000 which natively handles it... say other Windows players… for the DirectShow codecs and other specific things (if you want to play OGG files in Quicktime, or if you want to play them in WMP, etc) – read this page very well (and the documentation page while you're there) – this should have all the open source libraries and codecs you need to work with FLAC/VORBIS files system-wide: Xiph.org - Downloads

Also, for a good education about the many different forms of Vorbis based codecs like SPEEX, THEORA and similar "siblings", just hit this link or just scroll to the very bottom of the main home page for a nice summary of all their codecs, technologies and utilities/downloads/tools: Xiph.org - Resources by Project

Before you leave, don't overlook what I said about reading the documention: Xiph.org - Documentation

Not sure if it'd be of interest to you, but hey, better I offer it than not.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #13
i assume you mean the StreamTitle=xxx insertion? if so then there's not much which can be done about it if people use a v1 based DNAS or a v1 only client as that cannot be changed. if using a v2 DNAS and v2 compatible client then the metadata comes through in it's own 'metadata' packet type which is xml inside it so it's a lot more flexible over the v1 method though maybe xml wasn't a great idea since it's larger than it necessarily should be (but that's now something which is inplace so there's not too much which can be done to change it). there's more details about the specification and xml-based metadata here.
Yuck. I'll be tearing out all Shoutcast support in 1.2. Vorbis metadata (especially in sane clients like foobar2000) is literally as easy as dropping a new Vorbis comment into the stream between packets. That's how you do in-stream metadata properly. As an added bonus, when you rip that stream, it is magically an entirely valid Vorbis file, and it even uses the metadata as new-track markers.

shoutcast server & foo_vorbisstream-1.1_fix

Reply #14
thank you for the clarification on what you meant - i guess i'd never expected such a negative response, oh well each to their own.

it most likely is sane to just dump the Vorbis metadata into the packet but like i said most of this had all been decided on before i took on things so just changing things for a format which isn't even supported isn't something i'm going to be able to do. i'm not keen on the xml metadata itself though it's better than what went before (which i guess i naively assumed was what you'd be referring to) and i know it's never going to keep everyone happy (as has been proven).

As an added bonus, when you rip that stream, it is magically an entirely valid Vorbis file, and it even uses the metadata as new-track markers.
as much as i can see the bonus of that, i can also hear in the back of mind the corporate nightmare that would likely ensue since it just makes stream-ripping so simple.

has given me some food for thought on things so thank you for that.

-daz