Thanks for the info, Rob.

As for if I'd use different bitrates for different things: if I were playing the Ogg Vorbises through my Hi Fi, I wouldn't use Ogg Vorbis at all - I'd use Ogg FLAC. :)

Is Ogg FLAC more suitable for streaming than native FLAC or is there another reason why you'd use it?

Syd

On 2003.11.16 10:38, Syd Hancock wrote:

Next problem: say I want to have a second set of music files encoded at a different bit-rate.

As well as the built-in command lines for the encoders grip supports it also allows you to specify any command of your choosing as the encoder.

You can make use of this by specifying a shell script as the encoder - the shell script whould look something like this:

--------------- #! /bin/sh

filename="$1"; shift

# Encode at fixed 128 kbits lame -b 128 "$@" ${filename}_128.mp3

# Encode again using VBR (standard) preset. lame --preset standard "$@" ${filename}_vbr.mp3 ---------------

This will expect the output filename as the first argument and pass all other arguments on to lame (or whatever encoder you choose to specify) unchanged. All you need to do now is make sure grip calls this script in the required way so you would go to Config/Encode and change the "Encoder executable" field to point to your shell script and the "Encoder command line" to read:

%m %w

i.e. we don't pass the bit-rate from the grip configuration to the encoder but let the shell script do that. The other thing you would want to do is to remove the file extension from the "Encode file format" field as the shell script adds it.

The same technique would be applicable if you wanted to encode into more than one format - you'd write a shell script that called each of the encoders and then tell grip to call the shell script.

One further issue is that now there are two encoded files neither of which is called what grip expects, grip will not be able to add ID3 tags to the files. Many encoders can do this anyway so the answer would be to add whatever options your encoder uses for this to the command line grip calls the shell script with, so for lame this would be:

--tt %*n --ta %*a --tl %*d --ty %*y --tn %t --tg %G

Back to you original idea of writing a file to drive an encoder that already knows how to encode batches of files, you could write a shell script like this:

--------------- #! /bin/sh echo "$@" >> batch_file ---------------

you can then vary the format of the lines in the file by changing the "Encoder command line" field from within grip. The disadvantage of this approach is that ripping and encoding no longer happen in parallel.

HTH, Steve.

On 19 Nov 2003, at 11:16, Matt Parker wrote:

iTunes looks good on paper, until you start to delve into the DRM issue. Then it looks far more sinister.

At least it works (tm). Thank you and good night!

C

On 19 Nov 2003, at 12:13, MJ Ray wrote:

On 2003-11-19 11:58:39 +0000 Craig c@wizball.co.uk wrote:

...

On 19 Nov 2003, at 11:16, Matt Parker wrote:

...

iTunes looks good on paper, until you start to delve into the DRM issue. Then it looks far more sinister.

At least it works (tm). Thank you and good night!

Jam today, gruel forever after? Can someone throw me a link to something summarising iTunes's restriction support?

DRM doesn't apply to songs you encode yourself.... Oh look, at the end of the day, we're listening to music... isn't that like good enough for you? ;)

C

(Listening to cool tunes on my iPod)

MJ Ray mjr@dsl.pipex.com wrote:

On 2003-11-19 13:19:44 +0000 Craig c@wizball.co.uk wrote:

...

DRM doesn't apply to songs you encode yourself....

No, but it can apply to works encoded by others, even if they had gone into the public domain or made freely available.

...

Oh look, at the end of the day, we're listening to music... isn't that like good enough for you? ;)

I want to be able to listen to music tomorrow, as well as the end of today. This ability is harder to take away, but it can be eroded. For example, have you read "Right to Read"? http://www.fsf.org/philosophy/right-to-read.html

Coo, thanks for that, hadn't read that before :)

Brett.

On 2003-11-19 20:59:44 +0000 John Woodard mail@johnwoodard.co.uk wrote:

The prophecy it contains is very scary. I understand that this could be construed as FUD or scare mongering but even watered down it still scared the pants off of me.

Well, is it really FUD? It's quite clear that this is the worst imagined scenario, not what will happen for sure. Maybe I'm splitting hairs, but that's why I think it's different from the FUD we normally call FUD.

Maybe we should talk about this a bit at Syleham. I have some EFF and CDR things here somewhere, I think.

John Woodard wrote:

MJ Ray wrote:

...

I want to be able to listen to music tomorrow, as well as the end of today. This ability is harder to take away, but it can be eroded. For example, have you read "Right to Read"? http://www.fsf.org/philosophy/right-to-read.html

. Will my children not be able to share books when

they reach university? Will the copyright laws get to such a level that learning is forced underground? The seeds are planted today have they germinated? I fear they have and for one I am frightened for my children's and their children's future.

This document, and those referenced by it, were some of the key texts that first got me interested in Open Source/Free Software. I was aware that such software existed, but after having read about the possible future that laid ahead, I made a concious effort to learn more and eventually managed my first GNU/Linux installation. I also never looked at the software I had been using in quite the same way again.

What scares me is not the fact that these things could happen, but that they could be considered completely acceptable - and indeed things which many people already accept without question.

On 2003-11-19 17:16:31 +0000 Ben Francis ben@franci5.fsnet.co.uk wrote:

Btw, since this thread started, I've started using grip to rip CD's and encode them to ogg vorbis, and I love it :)

You might want to give jack a spin, sometime... not got all the fluffy GUI front end, but a nice simple, command line util with a set of progress bars as it rips, default config from debian is to encode oggs, which is nice... the first time it runs it'll set up a ~/.jackrc file, which you may want to edit... when you want to rip something, connect to the interweb (purely for the freedb lookup), plonk the cd in the drive, jack -Q, and watch it rip the CD. It's what I tend to use (screened) so that I can rip remotely, if needs be, and so that I don't rely on X staying alive ;) Also, you can edit the jack.freedb file after it's finished, and using jack -R have it magically retag and rename the tracks (useful in the event that the freedb data is wrong or if the CD isn't in freedb).

Just my 2ps worth,

Brett.