[Icecast-dev] MetaData Update for FLAC and OPUS
bn at radio42.com
bn at radio42.com
Wed Aug 21 06:33:26 UTC 2019
Thanks for your clear answer.
I'll try to contact the OGG, FLAC a Opus encoder developers at xiph.org.
As it currently seems, that there is no direct support for chained streams on the 'client-side' (encoder side) when using the reference encoders as provided by xiph.org.
As such I find it a bit odd to have no 'out-of-the-box' solution available at all.
Even if all/you say: it seems fairly easy to solve the issue on the client (encoder) side, I guess none of you have ever done it by using the standard tools available at xiph.org?!
If I am wrong, I would be very happy to receive some guidance on this, i.e. how can I provide chained streams on a continuous source when using the xiph.org reference encoders (e.g. FLAC or Opus)?!
Von: Icecast-dev <icecast-dev-bounces at xiph.org> Im Auftrag von Thomas B. Rücker
Gesendet: Dienstag, 20. August 2019 22:31
An: icecast-dev at xiph.org
Betreff: Re: [Icecast-dev] MetaData Update for FLAC and OPUS
On 8/16/19 6:10 AM, Bernd Niedergesäß wrote:
> I am a software developer myself. We develop a Radio Automation System/Broadcasting. Hence we are using the reference encoders.
> For OGG there is LUCKILY still the admin interface working to update meta data mid-stream.
As previously noted this does not do what you may think it does and its use for Ogg/Vorbis is discouraged by us. There are complex issues that this can cause and addressing them fundamentally would be complicated and time consuming.
Source clients that rely on this will provide unnecessarily poor and unreliable metadata to their users. The container supports complex metadata, while this hack modifies one field.
> That is why my post is related to the other ogg based formats: FLAC and OPUS!
We simply did not perpetuate the mistake that was made for Ogg/Vorbis, where it was not explicitly forbidden. As previously outlined, in case of Ogg encapsulation the only specification compliant and reliable way to have metadata is to generate a chained stream in the source client.
We understand that for software developers it's inconvenient to implement something differently if it feels like it should be as simple as the other thing, but as an open source project we are limited in the amount of work that we can reasonably take on. Embarking on the endeavour of modifying the stream that is sent by the source client properly, while maintaining consistency is neither enough of a priority, nor feasible with our limited resources. While on the client side it's incredibly simple in comparison.
We are happy to support developers in their effort of implementing chained Ogg properly and there are references like the IceS source. If you have any questions about it, please ask.
> As such please provide the same admin meta data update features as available for MP3, AAC and OGG also for FLAC and OPUS!!
Again, we are sorry, but this is not feasible.
MP3 and AAC do not use a container, but rely on a very limited title-field injection devised by Nullsoft for Shoutcast.
This supports exactly *one* field. If you see "Artist - Title" then this is actually a *single* string. Also there is no defined encoding and only 7-bit ASCII will work reliably for all clients, as some will assume
CP1520 others ISO-8859-1 and yet others UTF-8.
Streams that use a container *must* put their live metadata into the stream. There is no plan to support out of band updates.
>> Am 16.08.2019 um 06:06 schrieb renan jegouzo <renan at aestesis.org>:
>> you can try tracktor pro and see how it streams.
>> cause it handles it well: track's info updates in ogg without
>>> On 15/08/2019 20:48, bn at radio42.com wrote:
>>> Many Thanks for your answer.
>>> Actually quite a few 'ifs', 'maybes' or 'shoulds'... ;-) I have
>>> tried most of them (except liquidsoap).
>>> However, even the mentioned apps like RadioDJ or Mixxx do NOT support meta data changes via the encoder (they all use the admin interface)!
>>> And as you correctly pointed out: none of the reference encoders support this.
>>> Not even the FLAC, OGG and OPUS encoders listed on the common xiph.org site!
>>> Any this is actually my point: Why does a xiph.org tool like ICEcast demand a feature, which is not even supported by the other xiph.org tools?!
>>> As already pointed out in my last mail/post:
>>> It would simply be very user friend to offer a mid-stream meta data update, like it is offered for MP3 or AAC.
>>> This way also all reference encoders and many other tools could simply enable meta data updates in an easy way.
>>> This is all I am asking.
>>> And to be frankly: I have not heard a single good argument why this should not be possible.
>>> Many Thanks,
>>> -----Ursprüngliche Nachricht-----
>>> Von: Icecast-dev <icecast-dev-bounces at xiph.org> Im Auftrag von Roger
>>> Gesendet: Donnerstag, 15. August 2019 19:38
>>> An: icecast-dev at xiph.org
>>> Betreff: Re: [Icecast-dev] MetaData Update for FLAC and OPUS
>>>> On 2019-08-14 08:35, Bernd wrote:
>>>> Most users do use ICEcast to stream a continuous stream, e.g. they stream a live DJ or radio program.
>>>> I.e. they setup a single encoder on a single audio stream.
>>>> Still this logical stream contains different tracks being played over its time, and as such those users would like to update ICEcast to inform their listeners about the changing tracks within this program. This is a simple demand.
>>> I'm just going by vague memory here (I'm sure Philipp or somebody else will correct me if'm I'm wildly wrong), but a Ogg stream can have stream resets, basically the stream ends and a new start (but the data is continuous).
>>> I don't think any of the "reference encoders" support this, you may be able to do it by encoding the encoding and starting a new one.
>>> Your best best is to use liquidsoap or ffmpeg (note that the "ffmpeg Opus" encoder is said to have quality issues) or some other software.
>>> Any software that implements (or uses) libshout should have no issues embedding the metadata correctly in a Ogg stream.
>>> I'm not sure if you could use ffmpeg + the reference opus encoder and chain them via a pipe in some way (and have ffmpeg wait for a new encoder execution to connect).
>>> Maybe a PHP or Python script could be used to handle some of the logistics?
>>> BUTT (Broadcast Using This Tool) is opensource and supports metadata reading from a file and embedding this in the Ogg stream (as far as I know), if you feel like coding yourself (or having somebody else code for you) you could probably adapt that into something that works wit your setup.
>>> There are also software like Mixxx and RadioDJ that should have a proper Ogg stream encoder that can connect to Icecast servers. I'm unsure about the commercial software offerings.
>>> Roger Hågensen
>>> Unless specified otherwise, anything I write publicly is considered Public Domain (CC0). My opinions are my own unless specified otherwise.
>>> Roger Hågensen,
>>> Freelancer, Norway.
>>> Icecast-dev mailing list
>>> Icecast-dev at xiph.org
>>> Icecast-dev mailing list
>>> Icecast-dev at xiph.org
>> renan jegouzo
>> Icecast-dev mailing list
>> Icecast-dev at xiph.org
> Icecast-dev mailing list
> Icecast-dev at xiph.org
Icecast-dev mailing list
Icecast-dev at xiph.org
More information about the Icecast-dev