lioncash/droidsound — comment on commit 3e72d052c8d36e15fddcca40dccab5f5bb29db0e
File:  line 0
By alankila:

Lioncash kirjoitti 6.2.2012 kello 7.45:

> I need input on this one. Should VGMStream be put into this project. I think it should, in my opinion because it does play back some formats from games.

I have nothing against adding more playback engines, provided clean rules (preferably content scan) can be used to robustly and in crash-free way make positive identification of the file format. (In particular: no assumptions of minimum file data length, and no array out of bound errors because of blindly following offsets in a file.)

You may have noticed that I have basically moved the file scanning to be suffix based, in sense that file is only given to the plugins that claim to recognize its suffix. After suffix identification, plugin is requested to analyze the file and if it does not report a MusicInfo instance as result of the scan, it will move to the next plugin in list.

Earlier version of DroidSound had a configuration option to always perform the content scan, but I have removed it. Consequently there might be some misnamed files we could play but do not because the right plugin is not tried against them. More robust context detection might be welcome, so I'll probably change the API around a bit and use content detection immediately ignoring the filename if it seems that content detection with that plugin will work in a robust way. For HivelyPlugin and GMEPlugin at least there seem to be magic strings we can use. On the other hand, Amiga formats suck, so they must always be based on filenames. (Even UADE itself internally uses filename to choose the player.)

Metadata extraction would be best done via native code, but UADE and VICE probably will use java-side code no matter what: UADE because it can't give any metadata info other than selected player and things like that, so we need to explicitly support important formats' metadata extraction manually, and VICE plugin already has robust SID metadata parsing, so no need to do anything on native side to cover that.

--
Antti