caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Erik de Castro Lopo <mle+ocaml@mega-nerd.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] ANNOUNCE : libsndfile-ocaml alpha
Date: Wed, 3 Jan 2007 10:04:20 +1100	[thread overview]
Message-ID: <20070103100420.41ae28a4.mle+ocaml@mega-nerd.com> (raw)
In-Reply-To: <53c655920701021139u76c4bdd9p22efb30a0e44c07@mail.gmail.com>

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:

    http://savonet.sourceforge.net/ocamldoc/ocaml-vorbis/Vorbis.html

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


      reply	other threads:[~2007-01-02 23:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22  4:54 Erik de Castro Lopo
2006-12-27  9:32 ` [Caml-list] " Vu Ngoc San
2006-12-27 10:10   ` Erik de Castro Lopo
2006-12-27 10:42     ` Erik de Castro Lopo
2006-12-30 21:07     ` Erik de Castro Lopo
2006-12-31  3:31       ` skaller
2006-12-31  4:23         ` Erik de Castro Lopo
2006-12-31 11:08           ` Richard Jones
2006-12-31 22:51             ` Erik de Castro Lopo
2007-01-01 14:53               ` Matthieu Dubuget
2007-01-01 19:58                 ` Erik de Castro Lopo
2007-01-02  0:51                   ` skaller
2007-01-02  1:14                     ` Erik de Castro Lopo
2007-01-02  5:26                       ` Erick Tryzelaar
2007-01-02  5:39                         ` Erik de Castro Lopo
     [not found]                       ` <1167765505.5341.12.camel@rosella.wigram>
2007-01-02 22:37                         ` Erik de Castro Lopo
2007-01-02 23:46                           ` Gerd Stolpmann
2007-01-03  1:59                             ` Pal-Kristian Engstad
2007-01-03  2:49                             ` Markus Mottl
2007-01-02  7:47                     ` Christoph Bauer
2006-12-31 19:05           ` skaller
2006-12-31 22:54             ` Erik de Castro Lopo
2007-01-02 10:56       ` Vu Ngoc San
2007-01-02 11:27         ` Erik de Castro Lopo
2007-01-02 19:39           ` David Baelde
2007-01-02 23:04             ` Erik de Castro Lopo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070103100420.41ae28a4.mle+ocaml@mega-nerd.com \
    --to=mle+ocaml@mega-nerd.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).