I’m not sure that your link indicates that CoreAudio can’t create new files of a given type - just that it can’t overwrite existing files…
“There is however a limitation when working with MPEG-4 file types which include; .mp4 (kAudioFileMPEG4Type), .m4a (kAudioFileM4AType), .3g2 (kAudioFile3GP2Type) and .3gp (kAudioFile3GPType).”
“AudioFile does not currently support writing to existing files of these types.”
So if these guys were actually rational, you’d think the phrase “existing” would mean something - but then they go on to say:
“Therefore, if you provide the inWriteFunc procedure it is an indication to AudioFileOpenWithCallbacks that the file is being opened for writing, which in turn results in the kAudioFilePermissionsError being returned.”
which seems to indicate that you get an error if there’s ANY attempt to write. Bah.
But this is only MPEG-4 - surely mp3 files can be written this way, as well as .WAV or .AIFF…?
The other issue with these multiple codec formats is we need a way of specifying what type of file to write. I suppose the metadataValues argument could be hacked to take the first (or an keyed item) as the format type based on the extensions array.
URG.
Big bus crash there. Yes, this is a pretty serious issue with juce::AudioFormat in fact - it’s assuming that the AudioFormat uniquely determines the output file format - but this concept is made a mockery of by such AudioFormats as CoreAudioFormat and WindowsMediaAudio which could write multiple types.
I believe we need to have a new signature to createWriterFor, one which takes a file type:
virtual AudioFormatWriter* createWriterFor (OutputStream* streamToWriteTo,
const String& fileSuffix,
double sampleRateToUse,
unsigned int numberOfChannels,
int bitsPerSample,
const StringPairArray& metadataValues,
int qualityOptionIndex) = 0;
where we use the file suffix as a surrogate for the file type (since there is no pure “audio file type” identifier in Juce…)
The issue is making it backward compatible.
Thoughts?