| |
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 |
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: 3194 |
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. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
So how about this: the new format would allow any number of info chunks at the end, after the music data. Each chunk has a 4-byte ASCII name, followed by a 32-bit big endian unsigned integer of the length of its data (optionally: align all chunks, and round all lengths up to the nearest 4 bytes). The benefit of a format like this is that:
* Old players will just ignore the data at the end and can play new files.
* New players can parse and use the chunks they recognize.
* Unknown chunks can be ignored.
* As the format progresses you can add more chunks, and files stay compatible. Players can opt in to new features.
Suggested chunks:
* 2SID: Stereo SID info, two words for model and address
* STIL: STIL data
* TIME: One uint32 for each subtune with the number of frames that it should play. Flag if the tune repeats or stops.
* BUGS: Bug data
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quoting MagerValp
* TIME: One uint32 for each subtune with the number of frames that it should play. Flag if the tune repeats or stops.
It really should be a 16bit second count. Frames is not really usable, because in emulator libraries such as libsidplay2 you don't really know how many frames have passed. RSID tunes are basically just programs that run, the emulator does not call INIT/PLAY but just runs a full C64 program (PLAY is usually $0000 in this case). |
| |
iAN CooG
Registered: May 2002
Posts: 3194 |
indeed, not counting those sids that have irregular CIA timings (there are plenty) and those with timed play call, one every 5 calls for example. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
...but I am quite sure that the majority of tunes in HVSIDS have a duration that aligns evenly with a certain number of frames, but not with an even number of seconds? Easy conclusion: frames is a better choice.
One could also specify various alternative time formats that would fit different kinds of tunes better, I guess, but if one should go for one single duration time format, I cannot see why number of frames is not the best choice. The arguments provided so far did not convince. They sounded more like "hey, there is this exception to what you said, so what you said does not make sense at all." :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:As the format progresses you can add more chunks, and files stay compatible. Players can opt in to new features.
thats the "beauty" of a tag based format. everyone can invent their own new tags. AND THEY WILL. it could grow into something almost as awesome as id3 ! hell yeah! \o/ o_O |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quoting Frantic...but I am quite sure that the majority of tunes in HVSIDS have a duration that aligns evenly with a certain number of frames, but not with an even number of seconds? Easy conclusion: frames is a better choice.
So how long is a frame?
1/50 seconds?
1/60 seconds?
1/50.12 seconds?
One second precision is more than enough for this purpose, and a 16 bit value would be sufficient then. If you want to waste 32 bits on the song length, you could just as well use microseconds which would be almost cycle accurate. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
??
The duration of a frame is not an unknown value, and NTSC versus PAL is specified in the header anyway. The closer the value is to the real duration of a frame the better, of course.
For pal...
985248 / 312 / 63 = 50,1245421....
Use as many decimals as you like. :)
I find it quite disturbing when Deliplayer (on windows) cuts in the middle of a beat and things like that, when playing various amiga formats where the songlength can only be specified in seconds. I mean.. it is not that the unit of a frame is so wonderful as such. It is just that I fail to see why seconds would be better, since there is no inherent relation between "seconds" and the units of time that usually underly SID tunes. To me it is obviously more clean to cut the tune where it is in fact ending, rather than half a second off or so. Half a second is quite a noticeable duration when it comes to sound. |
| |
Sasq
Registered: Apr 2004
Posts: 156 |
CHUNKs is the way to go for sure. But I don't think trying to keep it compatible with the old format is a good idea, it may break things, and what's the point? If you're still using an old player chances are you're still using the old format files. And it's easy enough to add the format to the important players once it gets accepted.
The only problem with putting STIL into the file is the author-info; A bit unfortunate to have to duplicate the same information in every song by the same Author.
Also if we are worried about size, we can always use 16 or 8-bit tags where it fits, and actually end up with smaller files in many cases, like so;
"XSID", $????????
"IN", $0026 // Info (always $60 bytes in PSID)
"A", $04, "Drax" // Author
"N", $0a ,"Test Music" // Name
"C", $15, "198x Maniacs of Noise" // Copyright
"FL", $???? // Flags
...
"DA", $???? // Data
...
But that is probably not worth the extra complexity...
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
