| |
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....
|
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
MagerValp: Yep, that's the plan, I'm going to have to do some "real" work first, but should be easy enough to create a "converter" tool. I didn't want to call it v3 in the header as iAN said there's already a v3 in the works, so my version field will get set to 0x8002 (v2.5 ;-))
Once the converter is made, I'll create an updated version of TitchySID (just because I understand the source code). Then hopefully look at making an update to libsidplay (which would also let me recompile the Foobar2000 plugin, but after a quick look at the source code, I don't know where to start) |
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Converter - PSID V2.5 Converter
The converter will also let you convert V2.5 PSIDs back to V2
Further down the line I'll add commandline support so it can be batched, but next task is onto a player... |
| |
iAN CooG
Registered: May 2002
Posts: 3136 |
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: 1059 |
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: 3136 |
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: 3136 |
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: 1059 |
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: 3136 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
