On Wednesday 20 June 2007 22:00:51 Roger Dannenberg wrote: > Axel pointed out the sf_command interface and SFC_SET_CLIPPING parameter > in libsndfile. You're right! It's strange to change the scale factor > when you turn on clipping, but that's what happens. I still think it's > asking for trouble to scale differently on input and output by default, > but at least there's a simple workaround. > > However, I don't think ogg vorbis is supported -- not only did Eric just > tell me a couple people started but didn't finish an implementation, I > just downloaded libsndfile-1.0.17 and ogg_open() in ogg.c returns > SFE_UNIMPLEMENTED. Is there really an Ogg Vorbis implementation?
Oups, so I got that wrong. There were recently some emails about the vorbis implementation on the libsndfile mailing list at least so I did remember and I thought to have read that the implementation were finally available. But this not the case. So there is only this partially implemented thing in http://www.mega-nerd.com/tmp/libsndfile-1.0.12oggflac.tar.gz in the experimental code section of ogg.c. Maybe, if you have some money or man power to invest, it could be a good thing to invest them in finalizing the ogg/vorbis support in libsndfile. From what I get from the libsndfile mailing list Erik would likely be happy Sorry for the confusion, I completely agree with the scaling analysis below. Axel > Michael asked about distortion. Here's my analysis: reading 16-bit pcm > samples scales them by 1/32768. Writing scales by 32767, so the net > scale factor (with libsndfile default behavior) is 32767/32768. This > does not change values below 16K (the rounding bumps the samples back to > their original values) but subtracts one for values above 16K (let's > keep it simple by just looking at positive samples). So if you look at > the input-to-output mapping, it's equivalent to passing the signal > through a function that's linear except for a least-significant-bit > glitch at 16K. This is admittedly a small distortion, but with people > already questioning whether 16 bits is adequate for audio, wiring a > non-linearity into audio I/O seems unwise. If you iterate this map, as > in reading and writing a file repeatedly, each iteration subtracts 1 > from all samples over 16K, making the nonlinearity grow. Eventually, > everything above 16K is simply clipped. A similar thing happens with > rounding toward zero (as in libaudiofile), except the non-linearity is > at 0 and if you iteratively apply rounding, the problem does not get > worse. Eric (libsndfile) argues that the error is small and if you are > iteratively reading and writing integer samples, you are probably doing > something wrong. I agree, and my my main concern is just that having two > different mappings between integers and floats is bad practice. If I > pipe a file through a software mixer with gain set to unity, shouldn't > the samples come back out without modification? The SFC_SET_CLIPPING > option appears to fix this behavior. > > -Roger > > _______________________________________________ > media_api mailing list > [email protected] > http://www.create.ucsb.edu/mailman/listinfo/media_api -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 _______________________________________________ media_api mailing list [email protected] http://www.create.ucsb.edu/mailman/listinfo/media_api
