| |
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....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Well a standard precision float would do the trick as well, but that might be troublesome for embedded players (or the C64 for that matter). Milliseconds is a little too coarse, but how about 16.16 fixed point? Trivial to read out the seconds if that's all you need, 15 µs resolution, and max 18 hours of playing time. Or 9 hours and a loop flag. |
| |
Sasq
Registered: Apr 2004
Posts: 156 |
16.16 is a good idea I think.
So then perhaps we have these basic chunks;
HEAD - mandatory, with addresses and flags
DATA - At least one is mandatory, loaded into C64 mem
INFO - Optional
SLEN - Song lengths, 32 bits per song, optional
The STIL chunks may take a bit more thought...
One question is how the INFO chunk should look; simply the same 48 bytes as PSID, or sub chunks ("TITL", 0x00000010) or more compact (ID byte + length byte) ?
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Since HEAD would always be the first chunk, and it's useful to have a simple quick way of identifying the format, I would propose to call that chunk XSID.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you actually want a IFF based format, then using one tag for more than one kind of info is pretty much a nono though. why not have PSID as first tag then, put the entire old file into it, and then put new info into other tags? =) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Because lots of existing code checks for PSID, and then assumes that the data starts at offset 0x7c (i.e. ignoring the data offset stored in the header). |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Which is why you'd keep the old header and data to be compatible, and only add chunks of new information at the end. |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
MagerValp: Your first header wouldn't actually support the IFF format (ie, there's no length of the segment). Also you run the risk like I mentioned ages ago that if the PSID player just loads *all* data after the header (which I would guess was default behaviour), you have the possibility of overrunning the "C64" memory space in the player.
Might as well just wait to see what the HVSC team come up with for the new format now |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quoting pmprogMagerValp: Your first header wouldn't actually support the IFF format (ie, there's no length of the segment).
I'm not saying it would. I'm advocating that we keep the old header, and the old payload, and only add IFF-style chunks to the end, not that the new file format should be IFF.
Quote:Also you run the risk like I mentioned ages ago that if the PSID player just loads *all* data after the header (which I would guess was default behaviour), you have the possibility of overrunning the "C64" memory space in the player.
Yep, it's something to watch out for, and it'd be interesting to batch convert HVSC to this new format and see how big they get. I suspect that everything in HVSC would fit though.
|
| |
Sasq
Registered: Apr 2004
Posts: 156 |
I'm betting there are some tunes that end at FFFF which wont work. And if you play with a relocating player on the C64, many tunes with extra info may not work since they can extend into the area marked as free by the reloc-page.
Why not just create a clean, new format instead of another hack. With tools to convert back and forth it should cause problems for very few people.
|
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
For the time being we decided to take a compromise. In the new PSIDv3 format stereo sid support was added, zero termination of header fields was removed (increasing header string size by 1) and the old 28+3 filename limitation was removed. This change should be trivial to implement for sidplayer authors and it shouldn't break backward compatibility. Discussion about a version 4 hasn't really gone anywhere so far, please be patient. So far, thanks a lot for the input everyone! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
