I understand that there should be some way of including the info (.adf can't store it internally), but does it have to be in the filename for newer file formats?

It does get very tiresome having to strip all the rubbish off the ends, and remove the duplicates!

The file format of choice for the other scene I follow rejected the TOSEC naming standard as being unnecessary due to the fact that all that info could be included inside the file itself. With the CAPS project (or whatever it's called now) can that be the case? Or do the newer, more accurate dumps need to have the names polluted in this way? I do know that the new format is closed-source so if this info is not included, there may not be much chance that it ever will be.

At least, until the CAPS reverse-engineering that's being done is finished, at least! That's a good way off being completed though, despite progress being made

Dunny, I think you're missing the point of TOSEC. It tries to describe every different crack/trainer/fix of a game. Have you taken a look at the 'no intro' project? I guess not, because you still ask for something that you'll never see with the TOSEC naming convension So for the second time have a look at : http://www.no-intro.org

Dunny, I think you're missing the point of TOSEC. It tries to describe every different crack/trainer/fix of a game. Have you taken a look at the 'no intro' project? I guess not, because you still ask for something that you'll never see with the TOSEC naming convension So for the second time have a look at : http://www.no-intro.org

Yeah, I read about that when it was posted above, but thanks for assuming I didn't :-p

It's not what I'm after - I know there are other versions of games and utils out there, some with intros, some without - and let's face it, with the .adf format prevalent, we needed cracked versions so the copy-protection was removed.

I was probably not making myself clear - why can we not have a format that contains this information inside the file, rather than tacking it onto the end of the filename? Other scenes have managed this nicely (.TZX's "Archive Info Block" springs to mind here).

The only other disk format that we can possibly add this to (unless it already has, I don't know until I get hold of the file format specs when the free version is released) is the .ipf format. If the .ipf format can hold this info, then it will be of use to me in the Speccy scene, again once the GPL version of the format is released.

Not trying to be awkward here! I believe it's just high time we moved away from TOSEC's naming convention in favour of better ways of storing that info - the info that TOSEC aims to preserve is definitely necessary as part of the preservation effort.

...and yes the format itself could hold any info, but a real world preservation effort never ever stores data about data (again, metadata) embedded into the material being preserved itself.

They are independent entities, but there is a logical link between them.

I recommend you use this approach.

- Should the content be ever changed (however unlikely), your metadata remains valid.
- Should the metadata need to be changed (very likely, as you may re-arrange information, add, remove entries and so on) you can do it without changing the content.

We are talking about tons of content, and changing that content each time someone comes up with a new cool idea of information to be stored about it, is just pure non-sense.

I can understand why tosec chose to change filenames instead: it is a simple rename operation, not the change of hundreds of gigabytes of data.

I think you misunderstood what TOSEC is. The idea is not to create a list of the best possible dump for each game of each system, if you want a collection of that you will be better served using one of the options that people already pointed here.
TOSEC aims to identify / catalog all existent dumps for the existent systems, so anyone can pick some file out there and know what it is exactly, just that. You could try to get TOSEC dats without [b], [o], etc, or just [!] but if you really want to collect games for a system so you can play them the best thing is just grab a collection with that purpose. :P

About creating / using some kind of metadata included in the romfile itself, it has some beneficts but in my view the bad points are a lot more.
One of the main problems would be that every time you changed that metadata you would end up changing the rom hash (crc/etc) so it would be impossible to identify them. There are a lot more, you would still need to have diferent setnames do make all sets diferent and it would be much messier i guess, on sets with more than one romfile (instead of only one adf, etc) i suppose you would want to create some kind of container to put all files + metadata, and so on.

No i don't have the time to make a list of good and bad points of using what you pointed out, we know that tnc has the problem of making huge filenames in some cases (there is one with 181 chars) but nobody forces you to use it or even to have the entire dats/sets for a system, if you want a collection to play there are some way better alternatives, for cataloging and identifying all existent dupes we think that the current way is ok, not the best but for sure not so bad as some try to make it.

I think you misunderstood what TOSEC is. The idea is not to create a list of the best possible dump for each game of each system, if you want a collection of that you will be better served using one of the options that people already pointed here.
TOSEC aims to identify / catalog all existent dumps for the existent systems, so anyone can pick some file out there and know what it is exactly, just that. You could try to get TOSEC dats without [b], [o], etc, or just [!] but if you really want to collect games for a system so you can play them the best thing is just grab a collection with that purpose. :P

I refer the honorable gentleman to my previous post :-p

Quote:

About creating / using some kind of metadata included in the romfile itself, it has some beneficts but in my view the bad points are a lot more.
One of the main problems would be that every time you changed that metadata you would end up changing the rom hash (crc/etc) so it would be impossible to identify them.

That's not really an issue - one of the systems I use has a fileformat that is built of blocks - one of which is dedicated to the data, another to the metadata. CRC checking is done on only one of the blocks - the data block. As I said, I'm not after a perfect collection of dumps... the TOSEC Naming is useful when choosing which file to download, but what I am saying is that metadata can be handled a lot more effectively than adding to the filename. It's been done before, and it would be nice if the new format (ipf) could do it too. Unfortunately, I'll have to wait for the reverse-engineered version of the format before we can start to look at adding it

i don' think the naming and the storing are different matters, not for the common user / collector.

an ipf file that stores the info on what it is inside the file inside itself could be identified only by some tool reading it: it would be a slow and difficult way to manage files.
not to mention that everybody using any tosec archive should change its habits.

not only that, but any frontend like gamebase that required years of work to build a database should thow away that work, if it wanted to use this.

either way, someone should tidy the adfs anyway prior to store them in the new format, and that work is precisely what you point as your problem now.

I agree with IFW that metadata doesn't belong in the image file. I think the key to 'tidy up' the names is a new dat file with the best (read working) versions. We should really try to add the '[!]' tag to the TOSEC info which indicates a complete and completely working version. There is a huge amount of work necessary to do it, but I think it's worth it. On the other hand Gamebase features already a great number of these disks.

I like the naming convention too, except the many [a],[a1],[a2] and so on, probably many of them are not necassery.
Probably there are some versions of games in TOSEC, there the game has wrote data to disk, for example Highscores!
All information about dump in one filename - thats ok.
Sometimes [a] means there is a trainer on disk, so the file has incorrect,inexactly filename!

Quote:

Originally Posted by Another World

The [!] tag ?

I don't know, perhaps it has a meaning only when we are talking of "original" dumping, like an image of CDROM, for example