I’ve added a preliminary pull request to support Vorbis Comments and (the painstaking amount of) ID3 tags.
What has been done in this PR
Resaved the JUCE Demo, and added OGG, FLAC and WMA reading support to it.
Added a namespace to encapsulate Vorbis Comments and a tiny bit of functionality along with it.
Added a namespace to encapsulate ID3 tags and a tiny bit of functionality along with it.
Fixed a bug when enabling both OGG and FLAC: when trying to playback an OGG file, FlacAudioFormat was getting used to sample waveforms. Fixed by resorting the OGG/FLAC format order in the audio format manager.
MP3 ID3 tag support. (Can’t seem to find any details on this…)
AIFF ID3 tag support. (Can’t seem to find any details on this…)
Writing the tags, and testing the results, using all supported codecs.
Unit tests?
A Component that lists out all of an audio file’s metadata should be added to the JUCE Demo. Would be handy…
Things broken/questionable
I removed the existing OGG metadata keys… this breaks compatibility with JUCE, but none of those tags were official. Probably worthwhile putting them back in my PR - easily done - just making that change visible here.
My question is all-encompassing. Simply, I’m seeking the blatantly obvious: any indicators where the metadata is supposed to exist, and what each piece’s size would be.
By the looks of your shared code, the expectation for the v1 strings is 30 elements each? Do they have a guaranteed encoding - ASCII, UTF8…?
It looks like you github pull request has changes in all the images, project files etc. There is a lot of noise, removing some changes might make it easier for others to review?
EDIT: Maybe that is just refreshing the projucer projects? Maybe good as a separate commit?
Bumping this both here and there. Being able to read the tags would be a very nice feature and it looks like this might have been lost in the woodwork.
As to the patch itself, while I love how cleanly it splits out the architecture, I’m not so certain about the backwards compat breakage - though I’m not familiar enough with the culture here to know how acceptable such things are. If that is causing some recalcitrance to merge this patch then maybe leave the old API in place wherever it currently is, mark its usage deprecated, and fill its StringPairArray from the new source?
Simply bumping this as I’ve updated the branch and PR.
Echoing what Ricky said above, I’m not so certain about the backwards compatibility breakage but with JUCE 6 around the corner it could be worthwhile weighing these changes for the event of merging JUCE 6.