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

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

> However I can imagine that putting all the infromation into the SID file,
> would seriously complicate things for the HVSC crew. Any slight change

> in the song credits would require assembling a SID file from the start,
> instead of just editing a text file. But I guess a tool could automate 
> this task...

For now I wouldn't be worried about how information will be changed in the new SID files - first we should concentrate on getting the format right . I know that quite a few people in the HVSC crew are still using my SIDedit tool - that could be extended to deal with a new file format, too. I also created an Audio::SID Perl module which is freely available in CPAN - that can also be changed to deal with a new file format, which would make it possible to write Perl scripts that would automate such tedious tasks as updating textual data in SID files. And I'm sure others would come up with tools and scripts to help with the administrative tediousness.

Obviously, any kind of format switch will be painful for the HVSC crew at first, but I think it would be worth it in the long run. Consider this: currently, if just -one- STIL entry changes in HVSC, the entire STIL.txt file still has to be included in an HVSC update. If STIL entries were part of SID files, only that SID file would have to be included. Same with the song length info. So, a new file format would actually make the update process more efficient. Not to mention the original reason that started this discussion: the desire to have access to all this metadata without consulting those special files in the HVSC all the time - sometimes that is just not feasible (say, on a real C64).

> Anyway, if you manage to enforce a new format please don't forget to take

> care of the "speed" value for subsongs above number 32. This constantly
> causes problems for non-RSID files.

Duly noted!

> Also, I don't have a clue how the songlength calculation tool works, but if it's

> capable of telling that a song is looped, than maybe it can also tell
> where is the loop-point. If it can (or it can be done) I would like to see
> a field having the loop-point time apart from only the song's play time. 

> Also both these values should be as accurate as possible. Say, stored as a
> number of miliseconds or even better as as number of clock cycles or timer 
> ticks.


Several great points here. I know the songlength calculator tool written by Michael Schwendt can tell if a song is looping or not - in the current Songlengths.txt file any songlength with (x) means that the tune is NOT looping (with 'x' denoting the reason why), any other entry is a looping song. However, I do not think the tool is smart enough to figure out where the loop point is. It can tell you that a tune is 2:00 long after which it repeats, but I do not think it can tell that it restarts at, say, 1:05, instead of 0:00. I imagine that would not be easy to do.

Personally, I think milliseconds is an overkill for songlengths, but maybe 1/10th of a second provides enough resolution without bloating the file size. I would have a preference for seconds-based song length info, because that's what listeners are really interested in. However, a new file format could also store timer ticks or something like that in parallel with seconds/milliseconds/etc.

--

LaLa