Re: [Psid64-devel] SID file format (was: SIDDB)

[LaLa <la...@c6...>]

> I was thinking exactly the same, LaLa. Flexible offset sounds cool. And probably 
> also the least hassle if people are converting player applications. And 
> incidentially this is just what Wilfred suggested a year or two ago when we 
> already had this discussion for a short while.

I do not know how rigorous other software developers were when implementing PSID loader routines, but technically, they should reject files if they a) don't start with either "PSID" or "RSID", b) have a version number larger than 2, c) have a dataOffset other than 0x0076 or 0x007C. I'm just thinking of backwards compatibility here.

For example, my XMPlay SID plugin crashes (!) on Windows when I change the version number in a SID file to 3. Ouch. I know that my own Audio::SID Perl module (available in CPAN) can deal with a dataOffset other than the above two values (the rest of the header will go into a non-publicized data field called "PADDING"), but it takes any version number greater than 1 as meaning "version 2" - so, that would have to change, too.

One reason we switched the magic ID to "RSID" was so that non-RSID-compatible players would reject those files. We could do the same (say, use "XSID" for version > 2).


BTW, add Unicode UTF-8 support to my list of desired features. So we could have longer and linguistically correct "title", "author" and "copyright" fields. (We could keep the equivalent PSID fields for backwards compatibility, though - sort of how MP3 ID3v1 and ID3v2 can coexist.) That would also help with STIL entries, too. I have no clue how Unicode chars would be displayed by PSID64, though. =)

--
LaLa