On Fri, Nov 18, 2016 at 04:17:37PM +0000, Charles Keepax wrote:
On Fri, Nov 18, 2016 at 08:39:38AM -0600, Pierre-Louis Bossart wrote:
If you're debugging you may not care about the file format, you're actually interested in the raw data you get from the codec so dumping the output to a raw file would be useful even if you can't load that file into a music player.
While I agree with you on this, am worried that adding codecs may make people think that we can record mp3 file for exmaple, which is not the case.
I think we can add pcm and bespoke as formats supported and allow any format to be dumped to stdio. That way it is pretty clear to people ...
Crec as is it is pretty useless with PCM only...If we added the profile selection and things like bitrate information it'd be straightforward to support elementary bitstreams like MP3 or AAC ADTS, you just dump the data to a file. Things that require a header or MP4 integration would require additional libraries, this is no longer 'tiny'.
What about this as a suggestion, if we remove the code that adds the WAV header. Then all the output from crecord is raw data and the addition of any headers or additional wrapping is up to the user. That keeps crecord 'tiny' and allows us to support all the formats in a consistent way so no one gets confused.
Naah, crecord is a utility. If you need to do above you have tinycompress APIs to get the data and pack it the way you like.. You don't and shouldn't use crecord for that.
We haven't actually used the WAV header stuff since the very early versions of our firmware that didn't use compression on the stream and actually did output PCM data and I don't think anyone else has ever used the compressed interface for PCM.
Thats fine by me. The only reason we have a WAV header is that we can pack PCM files, for rest of the formats it become tricky as Pierre mention so lets not go that road :)