| |
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: "why not fix the SIDs anyway"
yeah sure, pick one from the buglist and fix it. Send anytime!
hint: if it's in the buglist means that no one so far was able to fix it, or it's even impossible due to missing/broken data. Good luck.
Okay, hands up, I'll admit, I only glanced at buglist and didn't read it properly. :-)
But that goes back to my point, tune times have a positive effect on being in the file format. STIL and BUGLIST don't because the player can do nothing with that information. Sure, maybe make them optional in the same way MP3s can have a jpg of the album cover, but not required.
Could you not use
Quote:+7A WORD reserved
in the SID v2 header (according to the file format document in HVSC) to point to a "Optional Data Header", which can then be located anywhere in the file (so not to throw off any players that assume a fixed header size, or just don't want to use it). Point this to a "floating" header record would mean that it wouldn't *break* any of your tools
What languages are the tools written in? |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
There has been a discussion about this in the HVSC team numerous times. I'd favor putting the playtime into the sid header, but the number of reserved/unused bytes in the header always prevented this (without breaking anything). The idea with the floating header record hasn't been brought up before and to me as a non coder sounds interesting. |
| |
Hermit
Registered: May 2008
Posts: 208 |
A primitive and dirty solution, but if there's no room and there are compatibility issues, why not storing song-length values in the filename's last characters....that could be checked and read easily by a simple text-routine...
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quoting Groepaz
Quote:
my favourite WTF is, that it contains the pointless md5 (wth should one do with this?) as regular data.... and the filename, which is what you really want, is only there as a comment, so everyone who uses the db ignores the md5, and then adds whacky code to seek backwards to last comment and extract the filename. awesome =) the times beeing in min:sec format and not seconds only as you most likely need in your app then is only a small annoyance. somehow looks as whoever invented this format didnt code a thing before =P
The idea is that the path name often changes. So the MD5 is a more robust way of identifying the file in question. So it's possible to extract the song length even if the file was not loaded from within the HVSC, as long as the MD5 is in the DB.
Btw, the whole system was designed and implemented by Michael Schwendt. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quoting HermitA primitive and dirty solution, but if there's no room and there are compatibility issues, why not storing song-length values in the filename's last characters....that could be checked and read easily by a simple text-routine...
Because there's often more than one song in a file. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
simply use the bytes left to point to the end of the sid file and stick the extra data there ? anyways I dont think switching to a new format would be the end of the world, why not? |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
The problem with having a "footer" (putting the extra data at the end of the file) is backwards compatibility. If older players that don't know about it read the header, then read the rest of the file into the emulated RAM till eof, it could be nasty.
|
| |
pmprog
Account closed
Registered: Nov 2005
Posts: 54 |
Quote: The problem with having a "footer" (putting the extra data at the end of the file) is backwards compatibility. If older players that don't know about it read the header, then read the rest of the file into the emulated RAM till eof, it could be nasty.
I don't think this will actually be an issue for the following reasons
1) The SID file formats do not contain any references to file size, so in order to read the file, it is highly likely that the allocated buffer will be the actual filesize.
2) Say all the data (including the optional footer/header) gets loaded into the C64 memory, the SID code won't access them, so it won't cause any playback issues
I guess the only downside to this is if the LoadAddress field in the header is close to the upper portion of the 64KB limit, and the data including the extra header information could overrun the buffer, but that leads me to...
3) "+04 WORD version" - Each PSID has a version. As this file would be a new version, older players would (should) validate it's a version they support.
2 |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Yeah, it would only really be an issue if the SID file was loaded towards the end of the emulated RAM. Whether coders of any players do anything other than check existing versions is another matter ;)
If something like this is done then maybe any future HVSC releases with the new data in could come with a "stripper" exe to run to revert the files back to the old format. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
The best is to have all crucial info in 1 header, and
not being afraid to make a new format. just do it.
if people want to support new format, they should do so.
This was designed in 1990 by PHS, and all the optimizations to it since, have been limited by "oh no, i have to not break compatibility"
I dont think that goes anywhere positive with a format that is so old.
Values in header, and STIL etc. in a real database format, and the key to read a tune's info, in the header. done!
If "Commando" has db key 147 for STIL and other stuff info, this key will never change. "Commando" stays at 147 forever.
We have been over this again and again, but when it came to the deciding things, actually making the things, real life came in the way every time, so its stranded.
AFAIK e already know a long time what to do, just e are all lame asses and didnt do it.
Ian: just because im not coding this, and because i have left the team because i have no more time, dont mean i dont have ideas, and have a right to speak them. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
