English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
ANNOUNCE : libsndfile-ocaml alpha
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-01-02 (23:04)
From: Erik de Castro Lopo <mle+ocaml@m...>
Subject: Re: [Caml-list] ANNOUNCE : libsndfile-ocaml alpha
David Baelde wrote:

> Ocaml-vorbis and ocaml-mad take strings as input.

Personally, I consider that a mistake :-).

I've looked a little at these interfaces say:


and just picking a single function:

    val encode_buffer : encoder -> string -> string

    Encode a wav buffer into ogg. WARNING: the size of the input buffer 
    should be less than or equal to 1024 bytes.

and there is no information about how the data is to be stored in the
input buffer. As someone reasonably knowledgable in audio processing
and audio file formats, I assume the the input string is pairs of
bytes, with each pair being a low byte and a high byte of a 16 bit
C short, with the endian-ness specified when the encoder is created.

So, the above interface you have created is perfectly adequate if all
you want to do is read from one file and write to another file. If
you want to do more than that; say read from a file, process the data
and then write to another file, then this interface is a pain in the
neck because you need to convert from the string data to an array of
into ot float, process and then convert back to a string.

> Reading data from
> libsndfile as string would allow a straightforward use of these libs
> together.

That is an argument that libsndfile should add read_string/write_string
methods. I am yet to be convinced.

> One might argue that having vorbis and mad work on float arrays would
> be better. That's a point. But on the other hand, the current
> datatypes avoid some conversions -- at least on the vorbis/mad side.

Conversion from short to float and from float to short (done right) is 
very, very cheap incomparison to the vorbis/mad encoding and decoding. 

I would argue that you would be unable to measure the difference between 
decoding to string and decoding to float array because the noise of
other factors like disk accesss, paging and other activity on the system 
would swamp the conversion time.

  Erik de Castro Lopo
"To me C++ seems to be a language that has sacrificed orthogonality
and elegance for random expediency." -- Meilir Page-Jones