Audio CD Moderation Guide - Revision history

>Mictlantecuhtle at 10:20, 26 January 2026

2026-01-26T10:20:28Z

← Older revision		Revision as of 10:20, 26 January 2026
Line 119:		Line 119:
	Session 1: 0-3487 -> (14887-11400)		Session 1: 0-3487 -> (14887-11400)
	Session 2: 14888-227278		Session 2: 14888-227278

			==Cuesheet Parsing Issues==
			A number of cuesheet elements for Audio CDs are unable to be correctly parsed by the site. To enable discs with these issues to be added, the elements should be removed from the cuesheet section and a note added to comments as follows e.g.:

			Following cuesheet elements unable to be parsed correctly:
			Row 1: CATALOG 0?
			Row 3: SONGWRITER "?"

	==Editions / Datfile versions==		==Editions / Datfile versions==

>Sadikyo: /* General Audio CD notes */

2025-10-02T13:53:19Z

General Audio CD notes

← Older revision		Revision as of 13:53, 2 October 2025
Line 11:		Line 11:
	Serial field is for serials present on the label of the disc, all other serials should be put in comments.		Serial field is for serials present on the label of the disc, all other serials should be put in comments.

	Track times taken from VGMDB may be incorrect, ~~recommend taking~~ times from ~~foobar2000 or other tools, or leaving times blank entirely~~.		Track times taken from VGMDB may be incorrect, please leave times blank unless taken from the item.

	Ideally, the contents should be listed exactly as on the item, for accuracy. This isn't always done of course. If you've confirmed it was done, please add the following line to the comments verbatim:		Ideally, the contents should be listed exactly as on the item, for accuracy. This isn't always done of course. If you've confirmed it was done, please add the following line to the comments verbatim:

>Mictlantecuhtle: /* Universal Hash match across multi-disc sets */

2025-02-05T12:35:48Z

Universal Hash match across multi-disc sets

← Older revision		Revision as of 12:35, 5 February 2025
Line 69:		Line 69:

	# Add the newly matching entry to the database following all of the usual processes and checks, but mark it as yellow (possibly bad dump). This ensures the entry remains visible in the database but without hashes being added to the DAT		# Add the newly matching entry to the database following all of the usual processes and checks, but mark it as yellow (possibly bad dump). This ensures the entry remains visible in the database but without hashes being added to the DAT
	# Add the following text in the comments of the newly matching entry: ''"This disc is a ~~reprint of and~~ Universal Hash match for [existing entry], but has been intentionally added as a separate (yellow) entry to ensure the completeness of this multi-disc set in the database."''		# Add the following text in the comments of the newly matching entry: ''"This disc is a Universal Hash match for [existing entry], but has been intentionally added as a separate (yellow) entry to ensure the completeness of this multi-disc set in the database."''
			## Additional commentary can be added where it is known e.g. that the new entry is a reprint of the older
	# Mark the existing entry as green (verified) and add the following note: ''"This disc is a Universal Hash match for [new entry], which has been intentionally added as a separate (yellow) entry to ensure the completeness of the multi-disc set/both multi-disc sets [delete as appropriate]."''		# Mark the existing entry as green (verified) and add the following note: ''"This disc is a Universal Hash match for [new entry], which has been intentionally added as a separate (yellow) entry to ensure the completeness of the multi-disc set/both multi-disc sets [delete as appropriate]."''

	==== Matching Universal Hash / different cuesheet ====		==== Matching Universal Hash / different cuesheet ====

>Mictlantecuhtle: /* Scenarios where matching Universal Hash should not currently be merged */

2025-01-27T14:19:42Z

Scenarios where matching Universal Hash should not currently be merged

← Older revision		Revision as of 14:19, 27 January 2025
Line 71:		Line 71:
	# Add the following text in the comments of the newly matching entry: ''"This disc is a reprint of and Universal Hash match for [existing entry], but has been intentionally added as a separate (yellow) entry to ensure the completeness of this multi-disc set in the database."''		# Add the following text in the comments of the newly matching entry: ''"This disc is a reprint of and Universal Hash match for [existing entry], but has been intentionally added as a separate (yellow) entry to ensure the completeness of this multi-disc set in the database."''
	# Mark the existing entry as green (verified) and add the following note: ''"This disc is a Universal Hash match for [new entry], which has been intentionally added as a separate (yellow) entry to ensure the completeness of the multi-disc set/both multi-disc sets [delete as appropriate]."''		# Mark the existing entry as green (verified) and add the following note: ''"This disc is a Universal Hash match for [new entry], which has been intentionally added as a separate (yellow) entry to ensure the completeness of the multi-disc set/both multi-disc sets [delete as appropriate]."''
			==== Matching Universal Hash / different cuesheet ====

			Occasionally, it is possible to encounter discs which have matching universal hashes but differing track hashes purely due to cuesheet differences (see https://redump.info/disc/105344/ and https://redump.info/disc/112883/ for an example).

			In this case, the entries should be kept separate and an appropriate datfile version applied (generally Alt), along with a note in comments in both entries stating "Universal Hash match with [matching entry] but differing track hashes due to cuesheet differences"

	== Other warnings and issues ==		== Other warnings and issues ==

>Mictlantecuhtle: /* Matching Universal Hash / different cuesheet */

2025-01-27T14:19:22Z

Matching Universal Hash / different cuesheet

← Older revision		Revision as of 14:19, 27 January 2025
Line 44:		Line 44:

	In scenario 3 above, note that the previous DIC track hashes should be replaced with the hashes of the redumper dump which correctly identified an offset. If scenario 2 applies, refer to the guidance above regarding Universal Hash and discs with different non-zero data starts.		In scenario 3 above, note that the previous DIC track hashes should be replaced with the hashes of the redumper dump which correctly identified an offset. If scenario 2 applies, refer to the guidance above regarding Universal Hash and discs with different non-zero data starts.

	~~=== Matching Universal Hash / different cuesheet ===~~

	Occasionally, it is possible to encounter discs which have matching universal hashes but differing track hashes purely due to cuesheet differences (see https://redump.info/disc/105344/ and https://redump.info/disc/112883/ for an example).

	In this case, the entries should be kept separate and an appropriate datfile version applied (generally Alt), along with a note in comments in both entries stating "Universal Hash match with [matching entry] but differing track hashes due to cuesheet differences"

	== Merging entries which have the same Universal Hash ==		== Merging entries which have the same Universal Hash ==

>Mictlantecuhtle: /* Merging entries which have the same Universal Hash */

2025-01-27T14:19:07Z

Merging entries which have the same Universal Hash

← Older revision		Revision as of 14:19, 27 January 2025
Line 64:		Line 64:

	Where possible, explanatory notes should be added to show which version/variant of a CD each ringcode and offset refers to - see https://redump.info/disc/94630/ for a good example of this		Where possible, explanatory notes should be added to show which version/variant of a CD each ringcode and offset refers to - see https://redump.info/disc/94630/ for a good example of this

			=== Scenarios where matching Universal Hash should not currently be merged ===
			==== Universal Hash match across multi-disc sets ====
			We sometimes encounter a situation where multi-disc soundtrack sets will contain entries which have a matching Universal Hash either for an individual soundtrack disc, or for all or part of another multi-disc soundtrack set. For example:

			* [https://redump.info/disc/121343/ Seiken Densetsu Ongaku Daizenshuu (Disc 04)] matches [https://redump.info/disc/99330/ Seiken Densetsu 2: Original Sound Version] (individual soundtrack)
			* [https://redump.info/disc/121346/ Seiken Densetsu Ongaku Daizenshuu (Disc 06)] and [https://redump.info/disc/121347/ Seiken Densetsu Ongaku Daizenshuu (Disc 07)] match Seiken Densetsu 3: Original Sound Version [https://redump.info/disc/99332/ Disc 2] and [https://redump.info/disc/99333/ Disc 3] respectively (matches across partial multi-disc soundtrack sets)

			In these cases, we want to ensure the completeness of one or both of the multi-disc sets in the database, but we do not want the generated DAT file to contain duplicated hashes. For now, the agreed process where a Universal Hash match occurs in this scenario is as follows:

			# Add the newly matching entry to the database following all of the usual processes and checks, but mark it as yellow (possibly bad dump). This ensures the entry remains visible in the database but without hashes being added to the DAT
			# Add the following text in the comments of the newly matching entry: ''"This disc is a reprint of and Universal Hash match for [existing entry], but has been intentionally added as a separate (yellow) entry to ensure the completeness of this multi-disc set in the database."''
			# Mark the existing entry as green (verified) and add the following note: ''"This disc is a Universal Hash match for [new entry], which has been intentionally added as a separate (yellow) entry to ensure the completeness of the multi-disc set/both multi-disc sets [delete as appropriate]."''

	== Other warnings and issues ==		== Other warnings and issues ==

>Mictlantecuhtle: /* Editions / Datfile versions */

2024-12-12T14:20:51Z

Editions / Datfile versions

← Older revision		Revision as of 14:20, 12 December 2024
Line 118:		Line 118:
	* 3DO Game Bundle (3DO)		* 3DO Game Bundle (3DO)
	* 3DS Game Bundle (3DS)		* 3DS Game Bundle (3DS)
			* AJCD Game Bundle (Atari Jaguar CD)
	* CD-i Game Bundle (CD-i)		* CD-i Game Bundle (CD-i)
	* DC Game Bundle (Dreamcast)		* DC Game Bundle (Dreamcast)

>Mictlantecuhtle: /* Editions / Datfile versions */

2024-10-10T08:13:45Z

Editions / Datfile versions

← Older revision		Revision as of 08:13, 10 October 2024
Line 121:		Line 121:
	* DC Game Bundle (Dreamcast)		* DC Game Bundle (Dreamcast)
	* FMT Game Bundle (FM Towns)		* FMT Game Bundle (FM Towns)
			* GB Game Bundle (Game Boy)
	* MCD Game Bundle (Mega CD / Sega CD)		* MCD Game Bundle (Mega CD / Sega CD)
	* Multisystem Game Bundle (same disc verified as being bundled with the game for multiple systems)		* Multisystem Game Bundle (same disc verified as being bundled with the game for multiple systems)

>Mictlantecuhtle: /* Editions / Datfile versions */

2024-09-16T15:04:36Z

Editions / Datfile versions

← Older revision		Revision as of 15:04, 16 September 2024
Line 129:		Line 129:
	* PC-88 Game Bundle (PC-88)		* PC-88 Game Bundle (PC-88)
	* PC-98 Game Bundle (PC-98)		* PC-98 Game Bundle (PC-98)
			* PCE Game Bundle (PC Engine)
	* PS2 Game Bundle (PlayStation 2)		* PS2 Game Bundle (PlayStation 2)
	* PS3 Game Bundle (PlayStation 3)		* PS3 Game Bundle (PlayStation 3)

>Mictlantecuhtle at 08:38, 13 September 2024

2024-09-13T08:38:23Z

← Older revision		Revision as of 08:38, 13 September 2024
Line 64:		Line 64:

	Where possible, explanatory notes should be added to show which version/variant of a CD each ringcode and offset refers to - see https://redump.info/disc/94630/ for a good example of this		Where possible, explanatory notes should be added to show which version/variant of a CD each ringcode and offset refers to - see https://redump.info/disc/94630/ for a good example of this

			== Other warnings and issues ==

			=== Large offset / default split causes audible cutoff ===

			In a few very rare cases where an Audio CD has a large offset, the default split may result in audio data being moved out of Track 01 and into a separate Track 00 file. Due to the way redump currently handles (or doesn't) lead-in/lead-out data, this may result in the dump having an audible cutoff at the start.

			In these cases, and only through careful consultation between staff and the dumper to investigate all other potential methods of handling the problem, it may be acceptable to add the dump using a forced offset of 0.

			If this is done, a note should be added as follows: Used redumper option --force-offset=0 as default split audibly cuts off Track 01

			=== Large offset / default split causes audibly incorrect track boundaries ===

			Similar to the above, in some cases where a disc has an offset that is out of spec (greater than +21065), redumper's default split / movement of data into Track 00 may result in audibly incorrect track boundaries (start of track X heard at end of track X-1).

			In this case a similar process to the above can be followed, and a noted added as follows: Used redumper option --force-offset=0 as default split results in audibly incorrect track boundaries

			[[Category:Moderation Guides\| ]]


	==Enhanced CDs==		==Enhanced CDs==