On Thu, 2003-05-29 at 19:14, Dominic Mazzoni wrote:
> Joshua Haberman wrote:
> > On Mon, 2003-05-26 at 23:00, Dominic Mazzoni wrote:
> >>Just a brief thought on the whole 24-bit issue: the main reason
> >>I originally put it in the least significant bytes was so that
> >>you could do DSP, and clip later. But I'm not sure that was a
> >>good decision. Now I think we're trying to always clip anytime
> >>wraparound is possible, which is probably the right thing to do.
> >>Here's a question: do we actually need to support 24-bit
> >>in memory? Maybe it would make more sense to only support
> >>16-bit int and 32-bit float internally, but write 24-bit ints
> >>to files as one of the options. There just aren't any good
> >>reasons I can think of for 32-bit ints with 24 bits of precision,
> >>instead of a 32-bit float.
> > I like the idea: let me see if I can understand how it would play out:
> > If the default sample format is 24 bits, then recording will capture in
> > float format, but save to a 24-bit BlockFile. I assume this takes full
> > advantage of the fidelity of 24-bit sound cards.
> > It will be an error to ask for 24-bit samples from a BlockFile, even if
> > the BlockFile is 24-bit.
> > Importers will create 24-bit BlockFiles if the source file is 24-bit.
> > Exporters will write 24-bit output files if the target format supports
> > it *and* the source track is 24-bit. But internally, it will look like:
> > (24-bit blockfile)->(float in-memory samples)->(24-bit external file).
> > Does this all make sense? I think this should happen before 1.2.0,
> > since it would be preferable to having half-baked and under-tested
> > support for 24-bit in-memory samples.
> I'll seriously consider this.
> I'm not positive it would need to be done before 1.2.0, though
Could it be though? I may be interested in trying this soon.
> - I
> don't really think that our support for 24-bit is as bad as you say,
> considering that 95% of the code either uses generic pointers or
> converts to/from floats before accessing samples. Only importing,
> exporting, reading and writing from blockfiles, and mixing need to
> support each sample format. That's really not all that much code;
> we just need more comprehensive unit tests.
I tend to see things as worse than they really are. :) Remember,
though, that unit testing led me to write the bug that we were seeing
earlier, because my confusion of how 24-in-32 was supposed to be
represented led me to write a bad test.
> Come to think of it, we could support 8-bit data. Worth it?
I doubt it. The space saving is only going to be useful for significant
amounts of data, and I can't think of any reason that you'd have large
amounts of data in 8-bit format (which sounds pretty bad). I don't
think the trade-off in complexity of code is worth it.