SIDedit.exe : sid header editor + disassembler, made in perl2exe, unmaintained. I personally don't use it but others find it handy. siddiag.exe : diagnostic of header/code errors, memory usage map, trims unused memory at end of sid file sidclean.exe : newer cleaner also trims at start if needed. still in beta but will replace siddiag and siplay2/hacked sidknown.exe : identifies duplicates by actually playing the sid and generating md5 hashes from the sid usage sidusage.exe : detailed usage checker, generates a map read by siderror siderror.exe : reads maps generated by sidusage and reports badreads/bad execution etc sldetect.exe : songleghts.txt generator, actually plays the sids to detect when they loop or stop emitting sounds to determine the lenghts sldb_merge.exe : accessory to sldetect.exe, to merge partial outputs eliminating dupes (so sldetect could be run on updates instead of the whole hvsc) siddump.exe : hacked to also dump the executed disassembly code mostly used to compare song output of similar/equal songs but also to spot execution errors
I don't see any major gain in having the time of every subtunes inside the sid, instead of having them in a separate file. If a sidplayer doesn't support yet the sldb (*) it won't support for sure the new format in future. Those sidplayers that already work with the sldb txt, what actual gain would they have by ALSO being able to read that info from inside the sid?
From what I've heard implementing support for Songlengths.txt is really tedious and requires lots of trial and error,