Support for alphabetical characters in the disk number metadata field

[scr1m3]

I have several albums that are multi-side and/or multi-disk vinyl's. WACUP allows you to save a disk number but doesn't support alphabetical characters. For instance, A or B would show as a blank disk number and 1A would just show as 1.

Just a nice to have.

[dro]

This might be tricky to achieve for the time being as track & disc numbers are assumed Winamp-wide to be integer values & not alpha numeric.

I might also need to double-check what the tag format recommendations. In this case is it just against MP3s or other formats?

-dro

[scr1m3]

I mostly use FLAC and MP3. I'll check some other formats later when I get home.

[scr1m3]

Tested ogg as well, same result. Not sure what other formats would be worth testing. I tried wma, which it seems isn't supported (I doubt anyone uses it anymore anyway)

[dro]

That's to be expected for OGG Vorbis based tags (as FLAC uses) since it just stores the data as string irrespective of what it is. I'd ignore WMA as I'm not including the plug-ins needed for that as part of a WACUP install going forward (it'll be possible to get them but it's a lesser used format & I don't intend on replacing the plug-ins for that anyway).

I'll have to do some research to see what can be done as it ultimately comes down to the input plug-in of the format as to how well it might work (even though I can pass a string version of the integer to them, if they then convert it afterwards (as I'm not sure if in_mp3 might do) then it'd defeat the point of things until there's a full stack replacement.

As for the media library (and for that matter anything that relies upon it for metadata), that's more of a pain since it is built to assume an integer value from what is local stored in its database to how it's provided to other plug-ins. I guess I could add a supplemental 'raw' version of the disc but that comes at the expense of slower library loads & searches & increased memory usage (which is something I'm trying to avoid with my w.i.p. replacement local library plug-in).

Will keep all of this in mind & look into it as time allows but this is something that I think can wait until a post 1.0 release along with getting more replacement plug-ins sorted out which would help alleviate some of the issues I'm aware off (which from a user view point don't make sense / shouldn't matter aka the implementation details).

-dro