[CSDb] - User Forums - Track Times in SID files?

You are not logged in - nap

CSDb User Forums

Forums > CSDb Discussions > Track Times in SID files?

2011-02-17 21:33

pmprog
Account closed

Registered: Nov 2005
Posts: 54

Track Times in SID files?

I've always wondered this, but why doesn't any of the SID file formats support a track time.

A couple of extra bytes per subtune per SID wouldn't be a huge loss, and it would mean any individual player doesn't need access to the 3MB file from HVSC to correctly know when to move on to the next track.

Given the database exists, it would also be pretty easy to write a program to go through all the files in HVSC, check if they match whichever SID file format supports the tracks times, and updates them with the tune lengths from the text file.

Does that not seem a good idea?

... 68 posts hidden. Click here to view all posts....

2011-02-21 13:01

Frantic

Registered: Mar 2003
Posts: 1635

Couldn't edit the last post when I was supposed to add:

...but I do agree that milli/micro-seconds would be more or less equivalent to frames for most practical purposes. Whole seconds, no...

2011-02-21 19:35

MagerValp

Registered: Dec 2001
Posts: 1060

OK, so an uint32 for the number of clock cycles that the tune should play. Divide by 985248 to get the number of seconds for PAL, or 1022727 for NTSC. Songs that cut mid-beat annoy me too. The only drawback I can come up with is that you get a max of 72 minutes.

@groepaz: Social media style tags have nothing to do with this. The format specification would define chunks and their meaning.

2011-02-21 20:13

chatGPZ

Registered: Dec 2001
Posts: 11182

Quote:

@groepaz: Social media style tags have nothing to do with this.

i know exactly what you mean :)
Quote:

The format specification would define chunks and their meaning.

which wont stop anyone from inventing their own tags - because they can. just look at id3 for example =)

2011-02-21 21:00

WVL

Registered: Mar 2002
Posts: 889

Quote: CHUNKs is the way to go for sure. But I don't think trying to keep it compatible with the old format is a good idea, it may break things, and what's the point? If you're still using an old player chances are you're still using the old format files. And it's easy enough to add the format to the important players once it gets accepted.

The only problem with putting STIL into the file is the author-info; A bit unfortunate to have to duplicate the same information in every song by the same Author.

Also if we are worried about size, we can always use 16 or 8-bit tags where it fits, and actually end up with smaller files in many cases, like so;

"XSID", $???????? "IN", $0026 // Info (always $60 bytes in PSID) "A", $04, "Drax" // Author "N", $0a ,"Test Music" // Name "C", $15, "198x Maniacs of Noise" // Copyright "FL", $???? // Flags ... "DA", $???? // Data ...

But that is probably not worth the extra complexity...

How to tell the difference from chunk

"A",$04,"Drax" // Author

and chunk

"ADDR",$02,$d420 // Address of 2nd sid

2011-02-21 21:05

chatGPZ

Registered: Dec 2001
Posts: 11182

the quotes are part of the tag in the file? :)

2011-02-21 21:15

iAN CooG

Registered: May 2002
Posts: 3145

Quote: How to tell the difference from chunk

"A",$04,"Drax" // Author
and chunk

"ADDR",$02,$d420 // Address of 2nd sid
?

infact tags should be always 4 bytes
AUTH for author
NAME
RELE as in RELEASED, and not COPYright, but it's true that an optional CREAtion tag could be added, if the exact creation date is known

2011-02-22 09:07

Sasq

Registered: Apr 2004
Posts: 155

Quote: How to tell the difference from chunk

"A",$04,"Drax" // Author
and chunk

"ADDR",$02,$d420 // Address of 2nd sid
?

In that example we assume that top level chunks are 32bit, 2nd level 16bit and 3rd level 8bit... but like I said, probably not worth it.

... although simply making all tags 16bit could be an option.

2011-02-22 09:40

jssr67
Account closed

Registered: Jan 2011
Posts: 33

Quote: OK, so an uint32 for the number of clock cycles that the tune should play. Divide by 985248 to get the number of seconds for PAL, or 1022727 for NTSC. Songs that cut mid-beat annoy me too. The only drawback I can come up with is that you get a max of 72 minutes.

@groepaz: Social media style tags have nothing to do with this. The format specification would define chunks and their meaning.

To make a connection between playing time from clock cycles and NTSC/PAL can be dangerous.
What about SIDs that try to detect NTSC/PAL and try to compensate the clock difference by setting different interrupt dividers, and using variable frequency tables? They do not have a constant number of clock cycles, but a more or less constant playing time.
SIDs that do NOT compensate, may have a constant number of clock cycles, an you may calculate the playing time then, of course. but can we take that for granted?

Could a solution be to have fields for playing time/nr of clock cycles for both "modes"?

2011-02-22 12:05

Sasq

Registered: Apr 2004
Posts: 155

This is all theoretical anyway, since songlengths.txt only contains seconds, and are those lengths are often off by several seconds.

Length is actual play time when listening, and not number of frames. Why not just use milliseconds, defined when playing with the specified clock, and PAL if not defined.

2011-02-22 12:32

jssr67
Account closed

Registered: Jan 2011
Posts: 33

Quote: This is all theoretical anyway, since songlengths.txt only contains seconds, and are those lengths are often off by several seconds.

Length is actual play time when listening, and not number of frames. Why not just use milliseconds, defined when playing with the specified clock, and PAL if not defined.

Just because the current solution is quite imperfect, does not mean it shouldn't be done better.

And there are possibilities to make it precise to less than a frame. And yes, that may matter. For example, if you have collections in which you want to have gapless song switching, because it was meant so by the author.

Using ms or any shorter fixed time unit is one option (frames of less than a ms may be uncommon). But letting the author decide by setting the appropriate tags and leaving the others open (so, he can say ms, frames, clock cycles... whatever suits the SID best) and the player then evaluates what has been given does not add too much complexity. And having the chosen tag for PAL as well as NTSC in the worst case adds one unnecessary tag. Or you can have 3: songlength/PAL, songlength/NTSC, songlength/ANY, given in any of the units stated.

Actually, I think discussing about the feature costs already more time than implementing the most flexible solution that you can think of. Cutting options is ok when it dramatically reduces complexity, I do not see that apply here.

Ah almost forgot, you asked why not just use timing for one clock: because then it is not stated if and how it varies between the standard clocks. It may not matter to you at the moment, but it is plainly incomplete, it MAY matter for some, and why create a new format specification that already has known holes from the start?

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next

Refresh

Subscribe to this thread: