savonet

Hi,

Two things:

You can control the result of your metadata rewriting by printing
metadata. The following wraps a source in a event handler that logs
all metadata:
s = on_metadata(fun(m)->log(m),s)

Next, iirc shoutcast uses the song metadata. If it isn't set, it's
possible (but I'm not sure) that liquidsoap creates it from artist and
title. If it is set to something like "Unknown" then your title and
artist metadata are lost.

Hope that helps,
-- 
David

On Fri, 18 Feb 2011 10:30:53 -0500, David Baelde <david.baelde@...>  
wrote:

> Hi,
>
> Two things:
>
> You can control the result of your metadata rewriting by printing
> metadata. The following wraps a source in a event handler that logs
> all metadata:
> s = on_metadata(fun(m)->log(m),s)
>
> Next, iirc shoutcast uses the song metadata. If it isn't set, it's
> possible (but I'm not sure) that liquidsoap creates it from artist and
> title. If it is set to something like "Unknown" then your title and
> artist metadata are lost.

I'm not too sure what you mean by 'iirc shoutcast'. How would I set this --
in 'sc_serv.conf'? If so, what sub-heading does it go by?

Secondly, I notice that you only spoke of Shoutcast. Is there something
similar that needs to be done in Icecast? Strangely, the fill-in(s)  
function
used to work quite nicely in Icecast when I was having the pause/resume  
problem.
Once that was resolved, the title thingy ceased to work.

Btw, thanks for your all your help! This is the last buggy-boo to resolve.
Everything else is working great!

Andre

>
> Hope that helps,


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hi Andre,

I was just saying that shoutcast uses the song metadata (this is not
configurable) which is sometimes surprising. If you observe the
problem with icecast then my comment is irrelevant.

It's interesting to hear that the problem is new... could it be that
an error slipped when you rewrote the script? For example, maybe the
icmp3 variable isn't actually used? (If you're unsure, you can send me
the file in private.)

On Fri, Feb 18, 2011 at 5:40 PM,  <kronos@...> wrote:
> Everything else is working great!

Really good to hear that!

Cheers,
-- 
David

Hi Andre,

Thanks for sending me your script (in private) and sorry for the delay
in my reply. It's as I suspected: your fill_in function is correct but
is actually unused in your script.

You write:
icmp3 = fill_in(sstol)
icmp3 = mksafe(.....switch([....sstol....]))
output...(...icmp3)

The first definition of icmp3 is overriden by the second, and so it is
useless. In terms of the graphs that we draw in the tutorials to give
an intuition of what you're doing, you're first defining a sstol node,
then creating a first icmp3 node connected to sstol by the fill in,
and then creating another icmp3 node connected (through several
operators including mksafe and switch) to the original sstol. So you
have two branches, but the first one is ignored in the following and
in particular isn't connected to an output, so it's never
pulled/activated.

A more sensible script would be:
icmp3 = mksafe(...switch(...sstol))
icmp3 = fill_in(icmp3)
output(...icmp3)

Hope this helps,

David

On Tue, 22 Feb 2011 05:15:10 -0500, David Baelde
<david.baelde@...> wrote:

> Hi Andre,
>
> Thanks for sending me your script (in private) and sorry for the delay
> in my reply. It's as I suspected: your fill_in function is correct but
> is actually unused in your script.
>
> You write:
> icmp3 = fill_in(sstol)
> icmp3 = mksafe(.....switch([....sstol....]))
> output...(...icmp3)
>
> The first definition of icmp3 is overriden by the second, and so it is
> useless. In terms of the graphs that we draw in the tutorials to give
> an intuition of what you're doing, you're first defining a sstol node,
> then creating a first icmp3 node connected to sstol by the fill in,
> and then creating another icmp3 node connected (through several
> operators including mksafe and switch) to the original sstol. So you
> have two branches, but the first one is ignored in the following and
> in particular isn't connected to an output, so it's never
> pulled/activated.
>
> A more sensible script would be:
> icmp3 = mksafe(...switch(...sstol))
> icmp3 = fill_in(icmp3)
> output(...icmp3)
>
> Hope this helps,
>
> David


Thanks David!

I see the problem, but the solution you propose would not be easy to
implement since
the 'value' of 'icmp3' changes with each time-slot, and I have no idea how
to
implement it into the current structure. I'm not sure whether moving each
'Fill-in
Title for ID3 Tag' within the Switch schedule would be feasible. I have an
uneasy gut
feeling it will not work.

What about an easier appoach?

How about renaming the 'fill_in' like this (keeping the fill_in() within
sstol's
'Show-block'):


	# === SSTOL ===

		...

		sstol = sequence([a,b,c,d,e)]


		# Fill-in Title for ID3 Tag
	
		. . .

		sstol = fill_in(sstol)  <=== changed from 'icmp3 = ...'


	# Switch Schedule
	
		icmp3 = mksafe(...switch(...sstol))
		output(...icmp3)


Would this work, or would 'icmp3' become unknown in the process?

I hope this will do the trick since it would involve changing only a few
lines of code. It sure would be wonderful to have it work as expected!

Blessings,
Andre



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hi David,

Well, I fired up today's liq script using ogg sources, and the
same problem cropped up again.

The ID3 tags, using the fill_in(s) functions work, but the titles are not
listed on Icecast, but they are on Shoutcast. Furthermore, there is no YP
listing on Icecast.

I had mentioned (privately) differences bewteen mp3 / ogg results in
liquidsoap.log that might explain why the ID3 tags do not work for OGGs.


*****


[snippet from liquidsoap.log]

MP3

For metadata: [ ("album",""), ("genre",""), ("comment",""),
("filename","/usr/local/www/rcr/mp3/csoc/today/
Classic_Stations_of_the_Cross.mp3"), ("status","playing"), ("year","0"),
("source","today-csoc-mp3-32(dot)pls"),
("initial_uri","/usr/local/www/rcr/mp3/csoc/today/
Classic_Stations_of_the_Cross.mp3"), ("on_air","2011/02/22 15:34:16"),
("rid","145"), ("artist",""), ("track","0"), ("temporary","false"),
("title","") ]


OGG

For metadata: [
("filename","/usr/local/www/rcr/ogg/csoc/today/
Classic_Stations_of_the_Cross.ogg"), ("status","playing"),
("vendor","Xiph.Org libVorbis I 20070622"),
("source","today-csoc-ogg-32(dot)pls"),
("initial_uri","/usr/local/www/rcr/ogg/csoc/today/
Classic_Stations_of_the_Cross.ogg"), ("on_air","2011/02/22 15:34:15"),
("rid","144"), ("temporary","false") ]

For mp3s, final part of a 'For metadata[,,,,,("rid","145"), ("artist",""),
("track","0"), ("temporary","false"), ("title","") ] whereas for the ogg:
'For metadata[,,,,,("rid","144"), ("temporary","false") ]'.


*****


The oggs seem to be 'missing' the '("title","")' part that I presume is
essential to pass the ID3 tags through the fill_in(s) function.

For the interim, I have reverted to using mp3 sources (and both Icecast and
Shoutcast list and also show the titles), but I'm puzzled why the ID3 tags
are not passed when I use ogg sources.

Any ideas how I can fix this without resorting to using mp3 sources?

Thanks,
Andre


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hi,

It's been a while and you may have found a solution in the meantime,
but I'll give a simple one in an attempt to close this issue. The
problem is that your fill-in function only rewrites existing metadata
entries (this is the essence of list.map) and thus does nothing to the
absence of "title" metadata for some ogg files. A simple fix is to add
the metadata, if missing, by inserting the following lines before the
big list.map(....):

  m = if not list.mem_assoc("title",m) then
list.append([("title","")],m) else m end

Cheers,
-- 
David

Hi David,

Thanks for the quick fix on this issue.

Before I implement this, referring to the issue of mp3 or ogg sources:
since either source is converted to pcm by liquidsoap, is there any
difference in the quality of resulting output between the two? I mean,
if I use mp3 sources, is the resultant quality better or worse than
if I use ogg sources?

If it makes no difference which one I use, then I might as well stay
with mp3 since it is working well.

Btw, whenever you get a chance, please add Rural Catholic Radio to
your list of 'Proud Savonet (and very satisfied) users'!

Thanks again!
Andre


On Thu, 03 Mar 2011 03:06:23 -0500, David Baelde  
<david.baelde@...> wrote:

> Hi,
>
> It's been a while and you may have found a solution in the meantime,
> but I'll give a simple one in an attempt to close this issue. The
> problem is that your fill-in function only rewrites existing metadata
> entries (this is the essence of list.map) and thus does nothing to the
> absence of "title" metadata for some ogg files. A simple fix is to add
> the metadata, if missing, by inserting the following lines before the
> big list.map(....):
>
>   m = if not list.mem_assoc("title",m) then
> list.append([("title","")],m) else m end
>
> Cheers,


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hi,

On Thu, Mar 3, 2011 at 11:35 AM,  <kronos@...> wrote:
> Before I implement this, referring to the issue of mp3 or ogg sources:
> since either source is converted to pcm by liquidsoap, is there any
> difference in the quality of resulting output between the two? I mean,
> if I use mp3 sources, is the resultant quality better or worse than
> if I use ogg sources?

The only difference in quality is the one you can expect from decoding
the files. It's hard to compare quality between codecs, depending on
the bitrate, etc. but roughly, if the MP3 and OGG files sound the same
to you when you play them locally (or if you know they both have a
good enough quality in themselves) then you can just use any format:
once it's decoded it's the same for liquidsoap.

> Btw, whenever you get a chance, please add Rural Catholic Radio to
> your list of 'Proud Savonet (and very satisfied) users'!

I had done it, just haven't published it yet. I didn't know how to
describe you, because the name says it all. Now I've decided to quote
what you just wrote:

* "Rural catholic radio":http://http://www.ruralcatholicradio.com is a
"proud (and very satisfied) savonet user".

Cheers,
-- 
David

On Sat, 05 Mar 2011 05:39:12 -0500, David Baelde  
<david.baelde@...> wrote:

> Hi,
>
> On Thu, Mar 3, 2011 at 11:35 AM,  <kronos@...> wrote:
>> Before I implement this, referring to the issue of mp3 or ogg sources:
>> since either source is converted to pcm by liquidsoap, is there any
>> difference in the quality of resulting output between the two? I mean,
>> if I use mp3 sources, is the resultant quality better or worse than
>> if I use ogg sources?
>
> The only difference in quality is the one you can expect from decoding
> the files. It's hard to compare quality between codecs, depending on
> the bitrate, etc. but roughly, if the MP3 and OGG files sound the same
> to you when you play them locally (or if you know they both have a
> good enough quality in themselves) then you can just use any format:
> once it's decoded it's the same for liquidsoap.

Thanks David! That's what I thought, but I needed confirmation as I have
about 3 gig of ogg files that are taking up server space. I can safely
delete them now.

>> Btw, whenever you get a chance, please add Rural Catholic Radio to
>> your list of 'Proud Savonet (and very satisfied) users'!
>
> I had done it, just haven't published it yet. I didn't know how to
> describe you, because the name says it all. Now I've decided to quote
> what you just wrote:
>
> * "Rural catholic radio":http://http://www.ruralcatholicradio.com is a
> "proud (and very satisfied) savonet user".

A minor correction: if you could capitaize 'catholic' and 'radio', it'll
be great. Also, is there any special reason for the double http  
('http://http://')?

> Cheers,

Blessings,
Andre
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/