View Single Post
  #37 (permalink)  
Old May 24th 15, 12:02 PM posted to uk.comp.os.linux,uk.rec.audio
Tony Houghton
external usenet poster
 
Posts: 5
Default Flac and Audio CD Health Checks

In ,
Jim Lesurf wrote:

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:


A question occurs to me prompted by the way the Flack Health Check
program works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle'
takes somewhat less than a second per tempfile.


Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially?


I'm calling flac to read successive 5-sec chunks from a flac file. Each
time the flac utility will presumably have to seek.


Let's make sure I understand what's going on here. You want your program
to analyse a flac file and to do this you're using the flac utility to
decode that file into raw data your program can understand?

I am aware there are many ways to do what I've done. However I've done it
so far in the way I found easiest and most familiar.


And because there wasn't really another way available in RISC OS.

If the reader and writer are separate programs use a pipe.


I may have done if I'd known how to. But in practice I wanted to get a
program that produced the required coconut without too much delay. So far
as I'm concerned, the purpose of the programs I write are to produce a
result. It's nice to learn more about programming, but that's not my
main aim.

I still don't know in sufficient detail how to use a pipe for this. But I
do now know how to set up a 'ramdisc' for myself. Which strikes me as a
perfectly reasonably method - and one I'm familiar with from RO.


You've gone to some trouble to learn how to make a RAM disc, you could
have spent that time learning about pipes. There are several drawbacks
to the RAM disc, eg requires root access to set up, no guaranteed safe
place to mount it, not portable to other types of Unix (eg Apple's OS
X), whereas pipes are the natural way to transfer data between programs
in Unix. It is more complicated than just calling system(), but it's so
fundamental there's almost guaranteed to be a decent tutorial in any
book about Unix programming.

If my assumption above is correct, you just need to do this, in place of
the system() call:

1. Create a pipe with the pipe() function.
2. Call fork(), and in the parent continue as before, except instead of
opening a file you can use fdopen() to read from the output of your pipe.
3. In the child replace stdout with the input to your pipe. I can't
remember exactly how to do that, but I think it's a simple function call
which will be explained in a tutorial.
4. In the child call one of the exec() family of functions to launch
flac, using its --stdout option. man system says execl() is its nearest
epquivalent, but it's worth looking at the others to see if one suits
your use case better. This basically replaces the child fork of your
program with flac, with stdout still hooked up to your pipe.

I'm not sure whether you were splitting the file into 5 second chunks to
avoid filling up a RAM disc, or because your aim is to analyse just 5
seconds at a time, but in the former case there's no need to do that
with pipes. You can just run one instance of flac on the whole file and
let the system handle the buffering.