| |
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.... |
| |
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! |
| |
MagerValp
Registered: Dec 2001 Posts: 1078 |
OK, cool.
Just for fun though I spent a lunch break adding chunks to sid files, but I got stuck on the md5 checksum in songlengths.txt. How is that calculated? The checksums in songlengths.txt is different from what I get if I hash the file with /sbin/md5 or python's hashlib.md5(). I also tried hashing just the raw sid data, but that didn't work either. |
| |
Steppe
Registered: Jan 2002 Posts: 1510 |
The whole core of the MD5 code is very small:
// Include C64 data.
myMD5.append(cache.get()+fileOffset,info.c64dataLen);
unsigned char tmp[2];
// Include INIT and PLAY address.
writeLEword(tmp,info.initAddr);
myMD5.append(tmp,sizeof(tmp));
writeLEword(tmp,info.playAddr);
myMD5.append(tmp,sizeof(tmp));
// Include number of songs.
writeLEword(tmp,info.songs);
myMD5.append(tmp,sizeof(tmp));
// Include song speed for each song.
for (unsigned int s = 1; s <= info.songs; s++)
{
selectSong(s);
myMD5.append(&info.songSpeed,sizeof(info.songSpeed));
}
// Deal with PSID v2NG clock speed flags: Let only NTSC
// clock speed change the MD5 fingerprint. That way the
// fingerprint of a PAL-speed sidtune in PSID v1, v2, and
// PSID v2NG format is the same.
if ( info.clockSpeed == SIDTUNE_CLOCK_NTSC )
myMD5.append(&info.clockSpeed,sizeof(info.clockSpeed));
// NB! If the fingerprint is used as an index into a
// song-lengths database or cache, modify above code to
// allow for PSID v2NG files which have clock speed set to
// SIDTUNE_CLOCK_ANY. If the SID player program fully
// supports the SIDTUNE_CLOCK_ANY setting, a sidtune could
// either create two different fingerprints depending on
// the clock speed chosen by the player, or there could be
// two different values stored in the database/cache.
And here's some clarification from Wilfred about this:
But the "selectSong(s)" is the not trivial part of the whole calculation which sets the songSpeed for every song.
If you convert the selectSong method in the loop, for the things needed for the MD5 calculation, you will get:
uint8 u8CiaSpeed = 60;
uint8 u8VblSpeed = 0;
for (i = 0; I < u16NumSongs; i++) {
if (!boPSIDSpecific) {
if (i < 31) // check tune 0-30 (bit 0 - 30)
boVbiSpeed = !(u32Speed & (1 << i));
else
boVbiSpeed = !(u32Speed & (1 << 31));// last bit sets speed for tunes >31
} else {
// old PlaySID implementation
boVbiSpeed = !(u32Speed & (1 << (i % 32)));
}
// speed setting
if (boVbiSpeed)
md5_append(&u8VblSpeed, 1);
else
md5_append(&u8CiaSpeed, 1);
}
Hope that helps, I don't understand a line of what's written up there. :-/ |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |