Good Morning David,
David Baelde wrote:
Hi Andy,
Your script looks good. A simple example with some of the advanced features.
On Wed, Mar 5, 2008 at 11:22 PM, Andy <[EMAIL PROTECTED]> wrote:
What I'd like is:
day track
randomly decide if i should play a jingle or not
day track
randomly decide if i should play a jingle or not
etc
Currently you have an average of 1 jingle for 1 song. I think what you
ask now is that there are never two jingles in a row. There are a
couple of ways to achieve that.
One of the earliest tricks was the delay() operator: instead of
putting jingles in your random() node, use delay(1.,jingles). With the
delay() around it, it will act as jingles, except that the
availability of a second jingle will be masked until 1 sec after the
broadcasting of the first. In effect, you'll get a day track after any
jingle. You can put an higher delay: with 10 seconds for example,
you'll have the guarantee that if after a jingle a day tracks lasts
only 5 seconds, there will be no jingle after it, and hence another
day track.
Another possibility is to use the "single" parameter. I was surprised
to see that it is only available in switch(). I'll have to think why I
only implemented it there and not in the base class of both switch(),
fallback() and random(). Anyway, there is a solution with switch():
switch(single=[true,false], # the first child can't emit twice in a row
[ (random.bool, jingle), # 50% chance to choose jingles, when
repetition is allowed, i.e. after day tracks
({true},day) ]) # it's always possible to choose a day track
The second solution is a bit more complex. But it also has a slightly
different behaviour, really based on track repetitions whatever the
durations, while the first one is more about durations. Sometimes it
matters: if not, choose the simplest.
## normalise and compress the audio
radio = nrj(radio)
By the way, we recently realized (on the Dolebraï radio) that
normalize() -- used inside nrj() -- can saturate. Actually we should
have opened a ticket about that in order to stress Sam and Vincent,
who wrote the operator. Instead I started using replay-gain:
precompute the ideal gain per track (using mp3gain and vorbisgain) and
use it. It gives a very nice listening experience, and avoids the
problems of dynamic normalization -- not only saturation, but also
some inherents to dynamicity. The recipe is not so simple as it
involves a couple elements, and I plan to document it eventually. If
you're interested, encourage me and it'll come sooner :p
Thank you so much for this excellent piece of concise information. I'd
trawled the documents a couple of times, and have to admit the
documentation is a little bit of a struggle at times!
I think for my implementation, since all my 'day' tracks are around 3-4
minutes long (they're songs), then the delay option is going to be
suitable, since the complexity of the second solution seems overkill.
I'll pop that into the script and give that a try today and see how it
fares.
I'm also glad you noted the point about nrj, as funnily enough I'd
started to notice some nasty audio output which does sound like
saturation and also sometimes over-clipping. I'm a little unsure how to
make it easy reproducable to submit a ticket, but will see what I can
find to help the guys out.
Your solution to the problem does sound rather complex, and quite
onerous resource-wise however, and I don't think my current playout
system would handle that method. However, here is my vote for that being
documented ;-)
I'm also going to pop my simple script into the wiki incase it can help
anyone in the future needing my simplistic approach, when setting my
system up I found the examples the best way of learning liquidsoap.
Cheers!
--
Andy
e: andy @ thebmwz3.co.uk
