Small brainstorm and background information :
First off, this dialogue has already been there, but I eliminated it.
There is more going on than just "do what you like", or "let the program behave to what you have";
Many things (if not near all) are about standards. Thus, e.g. assuming that many software anticipates on folder.jpg, it would not be wise to choose something else. In approaching your data you would be bound to this one software that is capable of dealing with ˙our "name", and all of the others won't work (upon your data).
Where above is already a good reason to use one name only (folder.jpg), there's many more reasons, of which only a few are so less ICT-related that thay can be explained. Sort of;
A text field indeed could hold the name you use. Technically, for everything in the program, there would be no difference whatsoever, when the data has to be approached "through" this field.
But now there's two names, like folder.jpg and folder.jpeg (and this is practice). Yeah, we could enter both in the text field, separated by a semicolon etc. But *now* the program is in trouble.
For everything that approaches the (existence of) coverart, it must try all the possibilities. Oh, by itself no problem, but since (obviously) at some start of programming this is not anticipated upon, a few things have to be changed.
And ICT mind now says : the latter is no problem, because the first ("standards") already determines that it should not be allowed.
Now think further :
Whether we use Dos "dir *.jpg" or Explorer and sort on extension, we can only and ever choose one type, right ? Now this is THE reason why you should not want it otherwise (I mean, do not use two or more types mixed).
From this follows that you are "allowed" to use one type only, and that could just as well comply to a standard, if it's there.
Done.
Well, not completely, because *now* you must have the ability to change things fast, and for that matter what Gerard came up with might be good for a solution (I did not try it, but I assume it works satisfactory). If this does not work nicely afterall ... I planned to have something like this in XXHighEnd anyway (like a boatload of data manipulation functions will be in there eventually, the deletion of coverart being a first example currently being there).
So ... all done now ?
Sadly, no. But from an unexpexted angle;
If you look at the principle of the Galery phenomenon, you 'll see (or learn) that it urges for mixing everything and all, and that "albums" as such are just a carryer of data. Yeah, physically you would store each album in its own folder, but from there on it doesn't do much anymore. I mean, if you'd create "Blues Tracks" and stuff all the according in there, the album as a carryer has gone.
But now there is a small complication;
Since we are able to deal with FLAC files, they will mix with WAV files. And this urges for the same problems as with the folder.jpg thing. This time, however, it is unavoideable; We can't rename everything to WAV.
The complication in the end is a technical one. Thinking of the "dir *.wav" is similar to the search options which can be used from within the program. It can't do "dir *.wav" and "dir *.flac" at the same time. It has to be two subsequent searches, taking twice as much time ... Or 10 times, when 10 file types are supported ...
If this is approached wrongly with the example of "dir *.*" you'll get the search result from Vista itself (by typing in the search field in the upper right of Explorer). You'll get albums and tracks and coverart mixed.
I don't say that our Bill did not understand, but I do say there is more to it to get these kind of things right.
Anyway you know now why the release note on FLAC says that it isn't coorporated in the search function at this moment ...
This must be setup decently.
Lastly the unexpected conclusion : when the wav/flac/ogg/mp3/ape whatever is solved decently, there is no reason anymore to apply the same to the folder.jpg et al.
The only thing left to decide for that is the "standards" thing again.
Peter
