| |
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....
|
| |
iAN CooG
Registered: May 2002
Posts: 3178 |
1) use a portable language
2) source? |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Oh yeah, was going to upload the source on the project page too, but I forgot. It's there now
Written in VB.NET, but should be easily run through Mono (though I haven't tried). It was stated on the Summaries page.
If not, I'll make a C command line version in a bit |
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
This proposed(?) 2.5 version suffers from the same problems as PSID 1 and 2, as it just adds three variable length fields at the end. A chunk structure, like IFF/PNG/TIFF/AIFF/etc, would be needed for future proofing. |
| |
iAN CooG
Registered: May 2002
Posts: 3178 |
iff has variable block lenght fields anyway, what's the difference? You have to state how long is each block anyway.
This format btw clashes with the new v3 format because the pointer at 0x7a is already used to set the 2nd sid address =) |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
@iAN: Well, of course this isn't going to be compatible with v3 because I've never seen the spec. Is it even published? I can't find it on the HVSC site
I was hoping we could find a way to put it in the "next" spec so everybody has access, but by the sounds of it, you aren't very keen on this idea (I can't understand why, as it would save having to maintain a separate bunch of "database" files).
That's fair enough, I suppose, but then it does kinda render my efforts pointless unless everybody has to convert their own files or a duplicate HVSC is created; and that is just absurd. |
| |
iAN CooG
Registered: May 2002
Posts: 3178 |
Quote: @iAN: Well, of course this isn't going to be compatible with v3 because I've never seen the spec. Is it even published? I can't find it on the HVSC site
I was hoping we could find a way to put it in the "next" spec so everybody has access, but by the sounds of it, you aren't very keen on this idea (I can't understand why, as it would save having to maintain a separate bunch of "database" files).
That's fair enough, I suppose, but then it does kinda render my efforts pointless unless everybody has to convert their own files or a duplicate HVSC is created; and that is just absurd.
We should maintain a separate database file until the new format is accepted and there are tools to use the new format without having to always convert from/back to old format. The appended block of extra infos is good to me. If there isn't any extra the file it's exactly as the current sid format. |
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
Quoting iAN CooGiff has variable block lenght fields anyway, what's the difference?
The difference comes in the form of FORM chunks that contain other chunks. It's as flexible as XML (but orders of magnitude easier to work with), and it's easy to make file formats that are both backwards and forwards compatible. |
| |
iAN CooG
Registered: May 2002
Posts: 3178 |
The v3 format is not yet made public, it just contain 2 new fields at 0x76 and 0x7a (sidmodel for 2nd sid and adress of 2nd sid), but at this point I think it should be rediscussed, if in future we want to apply the new extra block with sldb/stil/buglist the 2nd sid address must be put somewhere else to leave space for the extrablock pointer. |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Quote:This proposed(?) 2.5 version suffers from the same problems as PSID 1 and 2, as it just adds three variable length fields at the end. A chunk structure, like IFF/PNG/TIFF/AIFF/etc, would be needed for future proofing.
Yes, my v2.5 format was supposed to try and maintain compatibility, whilst offering the song lengths. It wasn't a reinvention of the PSID format
Quote:if in future we want to apply the new extra block with sldb/stil/buglist
I find it strange that you consider song lengths not sufficient for inclusion into the file (sorry if I keep repeating myself). Knowing how long a song plays for is just as important as which chip it runs on, and what at speed etc. I only included the STIL/BUGLIST options on my converter to make it seem a little more worth it.
Quote:This format btw clashes with the new v3 format
Actually, whilst I'm thinking... Who cares if you're using some fields in v3 that I'm using in v2.5 for different reasons. If the player bothered reading the file version, it'll know what to do with it. |
| |
iAN CooG
Registered: May 2002
Posts: 3178 |
Quote: Quote:This proposed(?) 2.5 version suffers from the same problems as PSID 1 and 2, as it just adds three variable length fields at the end. A chunk structure, like IFF/PNG/TIFF/AIFF/etc, would be needed for future proofing.
Yes, my v2.5 format was supposed to try and maintain compatibility, whilst offering the song lengths. It wasn't a reinvention of the PSID format
Quote:if in future we want to apply the new extra block with sldb/stil/buglist
I find it strange that you consider song lengths not sufficient for inclusion into the file (sorry if I keep repeating myself). Knowing how long a song plays for is just as important as which chip it runs on, and what at speed etc. I only included the STIL/BUGLIST options on my converter to make it seem a little more worth it.
Quote:This format btw clashes with the new v3 format
Actually, whilst I'm thinking... Who cares if you're using some fields in v3 that I'm using in v2.5 for different reasons. If the player bothered reading the file version, it'll know what to do with it.
I personally don't have any use of the sldb, I play the sids whatever I need, I don't let the program to decide how much by itself =) and it's not important as knowing the sidmodel. Playing a sid with wrong sidmodel means that you are not listening it as intended, listening a sid that is meant to loop, but making it break at the loop point to me is wrong.
Sid v3 is meant for stereo sids, but that doesn't mean they don't have a duration, stil and bug infos, so they will need the 2nd sid fields AND the extra block as any other sid file. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
