| |
Didi
Registered: Nov 2011
Posts: 487 |
PAL/NTSC vs. NTSC/PAL fixed
Can someone please explain how to use the video system tags properly, because I already had a little discussion with Moloch about that.
From my point of view, a crack with a NTSC-fix will be tagged PAL/NTSC, so original format first, followed by format it was fixed for. So PAL-fixed stuff should be called NTSC/PAL then. This also was common usage in the past, as far as I remember.
Maybe change the label to "any (PAL fixed)" or "any (NTSC fixed)" to make it clear. (Cannot always be determinded from the credits.) |
|
... 28 posts hidden. Click here to view all posts....
|
| |
Jazzcat
Registered: Feb 2002
Posts: 1044 |
Normally the order of which format appears first does not matter. However, some groups use:
PAL/NTSC = pal game fixed for ntsc
NTSC/PAL = ntsc game fixed for pal |
| |
Didi
Registered: Nov 2011
Posts: 487 |
That's the way I described in the initial post and which is common as far as I know. |
| |
Maxlide
Registered: Apr 2003
Posts: 31 |
Does it real matter in which order you write "PAL" and "NTSC" fixed in a release? I never really cared about this and also not the americans I talked to in the past. Sometimes fixers just wrote "PAL fixed" or "NTSC fixed" only. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
its not about how to write it in a release (noone gives a damn really), its about how to use it in this database. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Quote: Normally the order of which format appears first does not matter. However, some groups use:
PAL/NTSC = pal game fixed for ntsc
NTSC/PAL = ntsc game fixed for pal
ACK to groepaz IMHO here and JC describes it just fine as well as Didi. The database matters and clear definitions need to be applied.
From the database point of view therefore I think Didi and JC got it right. A detection of such (existence of pal to ntsc or ntsc to pal fixing routines) could probably even be roughly automated as over 80% of the releases will likely just check $02a6 and branch accordingly.
I was pointed at some late Legend/TSM releases however ( involving JC! :) ) stating the exact opposite on the release. Such "bad" namings within the release likely happened due to the regional preference of the fixer. These need to be overridden for DB consistency sake whenever proven to be originally PAL or NTSC I think.
References:
FLI Graph V2.2+
Firefox +1F (release here named "ok" - TSM intro states NTSC/PAL)
Amica Paint V1.5 [english] (release here named "ok"ish - see screenshot)
Mystery +F (is that actually fixed or broken upload reading peaceys comment? Didnt check myself :) The screenshot however ...) |
| |
Moloch
Registered: Jan 2002
Posts: 2928 |
Fixing releases was started by the NTSC scene. Early attempts to fix games, demos, and tools can be found here and on disks not transferred yet. As such, the terms used by the scene were coined by, yep, NTSC sceners; terms like "NTSC Fix", "NTSC'D", and later "NTSC/PAL". During this early time there was all sorts of partially and fully NTSC fixed PAL demos/tools floating around, traded privately between guys in the NTSC scene. Some importing groups experimented with NTSC fixing their releases and the majority of those early fixes were simple $d011 crash changes, ripping the music to lessen the flicker, etc.
It wasn't until later that fixing was part of the rules for magazines and used to get points in the charts. That is when PAL sceners and groups started to care if an NTSC fix was applied to a crack. Sure, earlier than that some PAL sceners didn't like that their precious PAL only intros were ripped from cracks, but thats life.
There is a discussion going on in the moderator forums about this and I've suggested a better solution because using NTSC/PAL and PAL/NTSC will continue to cause confusion in the future here. Anyone that is currently involved with CSDb as a trusted user or staffer knows the constant nonsense dealt with about people ignoring even the most basic of written rules/guidelines.
New values proposed for video system option would be ...
unknown
any
NTSC only
PAL only
NTSC fixed
PAL fixed
Using "NTSC fixed" instead of "NTSC/PAL" removes the confusion shown by many in this thread. Also "NTSC Fixed" implicitly means the release originated on PAL and fixed to work on NTSC. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Molochs' proposal would clear out any questionable tagging so it is getting my +1 as it is also resolving/circumventing e.g. "NTSC/PAL" to "NTSC/PAL fixed" which are different cases as well. (Yes, sounds as bad as it would be.)
Of course: it also allows maximum incompetence on adding new entries with "bad" video system tagging by inexperienced users but thats life and we'll have to see how to teach people then :) After all we'd love to see recent scene newbies to enter the fixing scene as well, no? |
| |
Didi
Registered: Nov 2011
Posts: 487 |
"any (PAL fixed)" or
"any (NTSC fixed)"
would be suitable alternatives to "PAL fixed" or "NTSC fixed" as well IMO.
Those video system tags would make sense on nearly any executable release type, not just cracks. |
| |
Moloch
Registered: Jan 2002
Posts: 2928 |
I'd like the release properties (video, proper, import, preview, etc.) added to all release types in the end.
Right now there is a work around so you can add all these release properties to any entry by selecting C64 Crack category, tick the properties you want, then select the true category like C64 Tool or C64 Game and save. The properties will display with the new category. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Didi: "any" best describes a release which doesn't require fixing in the first place. "unknown" is for incompetence and laziness sake.
I don't really like "the implicity" of "NTSC fixed" either but there doesn't seem to be a better or more clear wording as obviously the links I referenced show how different this was used over the years. |
| Previous - 1 | 2 | 3 | 4 - Next |
