gdrom chds files will fail with a 'NoTracks' error

[i30817]

This function:

imageparse/src/chd/track_metadata.rs

Line 72 in b95a705

pub fn cd_tracks(metadata: &[ChdMetadata]) -> Result<Vec<CdTrackInfo>, text_io::Error> {

only considers cd rom tracks as tracks

and this code:

imageparse/src/chd.rs

Line 183 in b95a705

let chd_tracks = track_metadata::cd_tracks(&metadata[..])?;

then sends a error if a chd gdi is opened.

Is the code not ready to use the other functions for gdi chds?

[Manorhos]

No, this crate is currently only for CD images.
I have no idea how GD-ROMs work, would the current API which just supports setting the location with MsfIndex and getting a 2352 byte raw CD-ROM sector even be enough to access GD-ROMs properly?

[i30817]

Since another program converts gdi chds to cue/bins and says this in the code:

These systems use GD-ROM media, which needs special handling.
chdman does support GD-ROM dumps, but it only supports converting them to and from .gdi format and not to and from .cue format (it will attempt the conversion to or from .cue format, but the results will not be correct, at least as of chdman 0.240).
The Redump Datfiles use .cue format, but we can still use chdman to get the correct .bin files by telling it to convert to .gdi format, because the .bin files are the same for .gdi and .cue format dumps.
We then manually convert the .gdi into a .cue to verify it against the Datfile.
The Dreamcast discs with "(Unl)" in the name are unlicensed games that were distributed on CD rather than GD-ROM, and we ignore those here so that they are handled using the normal .bin/.cue processing.

I believe that the tracks themselves are equivalent and any differences occur in the metadata and there should be a 'way' to get the same kind of representation for both since cue/bin redumps bins are the exact same and that project does produce a 'working' redump cue just from contextual data in the metadata.

In fact from the behavior i'd feel zero surprise if the chdman output in the tag was the same except that one is marked 'CHTR' and the other 'CHGD'

[i30817]

The only difference in the metadata from the second form of track metadata in cds appears to be that gdi has a additional 'pad' property
https://github.com/mamedev/mame/blob/bb1b50429419b70f8912e81f07d4778824aa3a4d/src/lib/util/chd.cpp#L37

Not sure if that reflects on the track bytes, since redump (apparently) has the same gdi and cue track data, and when they switched to cues kept all the track data - either they have that value to none or it's a transformation that is only reflected at runtime. Something which might make it problematic to check the track sha1.

[Manorhos]

It still isn't completely trivial to implement GD-ROM support I think. For one, the discs can hold quite a bit more data, which results in MSF indices with a minute field larger than 99, which currently aren't supported.
Also, it seems we have to distinguish between low-density tracks which would be visible on a standard CD player or CD-ROM drive, and high-density tracks for the Dreamcast.
It's probably possible to hackishly support these discs just to be able to get the hashes, but the crate currently is in a quite messy state already...

[i30817]

Also finally. https://pypi.org/project/chdimage/0.1.5/

You can try your project in python now, if you want to. Well, the chd part at least.

edit: uh, there is a weird thing.

i3@sleipnir:~/Documents/Projects/chdimage$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import chdimage
>>> dir(chdimage)
['Event', 'GdiChdError', 'HdChdError', 'ImageError', 'MsfIndex', 'OrphanError', 'TrackType', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', 'chdimage', 'open', 'open_with_parent']
>>> dir(chdimage.chdimage)
['Event', 'GdiChdError', 'HdChdError', 'ImageError', 'MsfIndex', 'OrphanError', 'TrackType', '__all__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'open', 'open_with_parent']

How did that happen.

edit: appears to be from maturin doing it automatically, so it can be called directly. Pity there is no way to hide the inner one.

[i30817]

What about moving the factory methods that build MsfIndex to the chd struct, or taking it as a argument to get the bounds/type?

That way the factory could know which type of chd it is operating on, so it could instantiate different types of chds indexes, with different ranges and that would fail comparing to different types or not to the intended chd (well, if you want to).

That way you could even handle 'weird' cds that burn 'more than they should be able to' by doing strange things with cd burners, and wouldn't need to hardcode the limits (i think), and could fail immediately when a out of bounds read is created instead of just when it's attempted just like now, (unless that is desired, which it may be for a emulator, now that i think about it).