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

[Steppe <st...@de...>]

Hi LaLa,

LaLa schrieb:
>  > 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...

Roland, I can't agree here. Changing a single bit of info thus far is done by a 
simple command in the update script, so if you include more commands in that it 
doesn't get more complicated at all. Just adapt the script to cope with commands 
like these:

PLAYTIME
# auto sldb is far off by over a minute
/MUSICIANS/D/DRAX/Clarencio.sid
3:31 (G)

STILTITLE
# albuminfo added
/MUSICIANS/D/DRAX/Clarencio.sid
Clarence's Dream [from blablba]

It's absolutely the same in green. And with Lala's Sidedit updated at the same 
time it would really make no difference at all.


> 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).

That sums it up pretty nicely. From an administrative point of view it's not 
much difference where you have your information stored. It's the way you access 
and change the info that matters.


>  > 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.

Actually the Songlengths db does say if a song loops or goes silent.
If the songlength entry says 2:20, it loops at 2:20, easy as that.
If it says 2:20(G), 2:20(Z), 2:20(M), 2:20(B), it doesn't, but goes silent at 
that time mark.


> 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.

Seconds should really be precise enough, let's not be more precise than 
necessary, please.

Now for something different: Who actually is to decide about the fileformat? I'm 
just asking because I got some quite discouraging feedback from the crew, along 
the lines of "Nah, it worked ever since, why should we change" or "I like it the 
way it is", constructive stuff like that. So before we start investing too much 
of our time here I'd like to clear up who has the final say.

Regards,
Stephan