Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-23 16:38
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.
2011-02-23 17:25
chatGPZ

Registered: Dec 2001
Posts: 11296
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? =)
2011-02-23 19:21
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).
2011-02-28 00:14
MagerValp

Registered: Dec 2001
Posts: 1065
Which is why you'd keep the old header and data to be compatible, and only add chunks of new information at the end.
2011-02-28 08:36
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
2011-02-28 10:58
MagerValp

Registered: Dec 2001
Posts: 1065
Quoting pmprog
MagerValp: 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.
2011-02-28 14:56
Sasq

Registered: Apr 2004
Posts: 155
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.
2011-02-28 19:41
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!
2011-03-01 16:48
MagerValp

Registered: Dec 2001
Posts: 1065
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.
2011-03-01 19:34
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 77
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Wonderland XIV  (9.6)
8 Comaland 100%  (9.6)
9 No Bounds  (9.6)
10 Unboxed  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Morph  (9.5)
8 Dawnfall V1.1  (9.5)
9 Onscreen 5k  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Nostalgia  (9.3)
4 Censor Design  (9.3)
5 Performers  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.204 sec.