| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Please stop "cleaning" disk images
... or at least after you do so, test if the damn release still works after doing so. not seldomly there is other stuff on the disk that is needed - and its not necessarily obvious, or even visible in files. it really sucks to find those non working things when it is obviously the result of someone trying to "optimize" the image. ideally also attach the non cleaned image - that also keeps the context with the other games on the disk intact, which is sometimes kinda interesting to see.
thanks. |
|
... 21 posts hidden. Click here to view all posts....
|
| |
Thierry
Registered: Oct 2009
Posts: 48 |
Good point, I have several releases that are not in CSDB, I'll be a good idea to load the image without cleaning, image.no clean.d64
retrocomputacion.com
Argentina |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
Great, bring them on! :-) |
| |
TheRyk
Registered: Mar 2009
Posts: 2241 |
yeah especially if download files are flagged "broken", upload the complete image in question as transferred, not only .prg and no modifications |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
I opt for both, though - a cleaned version, to make life for the SID checkers like Fred easier, and one original version. |
| |
Mr.Ammo
Account closed
Registered: Oct 2002
Posts: 228 |
Quoting TheRykyeah especially if download files are flagged "broken", upload the complete image in question as transferred, not only .prg and no modifications It seems that the broken property can only be used when the release concerns a crack. While it should also be used for other releases that break, people tend to use the corrupted files flag instead. Which is a no-no according to:
Quoting CSDb rulesThe "Goofs" field and "broken" tag is aimed at the scene release in question. A goof is meant to document bugs in the release; for a crack that means bugs inflicted by the cracking group - not bugs that is in the original game. The "Broken" tag is used for signalling a broken release, again inflicted by the crackers or coders for example. For demos "broken" can be used if a release crashes and a newer version that works exist. Don't confuse the "broken" tag with the corrupted files (a bad copy, where the disk is trashed), that is covered and tagged editing the file in question when uploading. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
No. these are two different flags. one is per file (and can be used on any file) and its for marking actually broken files (not broken releases). the other is for marking broken cracks, and that is for marking fucked up cracks, not broken files. |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
"For demos "broken" can be used if a release crashes and a newer version that works exist." That refers clearly to the "broken" tag (like for cracks), not the "corrupted" flag for the download.
Good point, in fact, although those cases are probably rather rare. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
Especially my dumb spread notes from '90ties :D |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Quote: I opt for both, though - a cleaned version, to make life for the SID checkers like Fred easier, and one original version.
This is the wrong reason but thanks for adding cleaned disks :-)
The real reason for adding cleaned disks is of course that the release entry is about a release and not about a spreaded disk where the release was on. There are other sites for dumping disk images.
We have many comment fields for a release entry for preserving info that is found on a disk or on a release. No need to add uncleaned disks for this.
Anyway, always add a clean disk to a CSDb release entry. The uncleaned disk might be added but really not needed. It only makes the release entry 'dirty'.
Bottom line is that after cleaning a disk, always test the release and double check if all the files from the release are present. Also check for useful info on the uncleaned disk that can be added to CSDb.
If you're unsure that you missed something from a disk, you can always add a comment from which disk of which collection the release was found. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
The point is that you can hardly ever test multi-file releases properly (that is at least true for most games). And that means adding an unmodified disk is a must. "cleaning" also destroys the context of the release-disk, which really noone ever bothers to add to the entries. Also the release disks by themselves are artefacts worth preserving, including dir stamps, notefiles and what not. ripping out the releases and putting them on blank d64s just so emulamers can do clickyclickyautostart is simply lame. |
| Previous - 1 | 2 | 3 | 4 - Next |
