chdman 0.263 error does not compress dreamcast games

[CorvuzSoli]

MAME version

0.263

System information

Windows 10

INI configuration details

No response

Emulated system/software

No response

Incorrect behaviour

chdman 0.263 error does not compress dreamcast games, I tried with version 0.262 and it also has that problem.

Expected behaviour

I tried with version 0.261 and I had no problems with it.

Steps to reproduce

C:\Users\xxxx\Desktop\chdman> for /R %i in (*.cue *.gdi *.iso) do chdman createcd -i "%i" -o "%~ni.chd"

C:\Users\xxxx\Desktop\chdman>chdman createcd -i "C:\Users\xxxx\Desktop\chdman\Star Wars - Episode I - Racer (USA).cue" -o "Star Wars Episode I - Racer (USA).chd"
chdman - MAME Compressed Hunks of Data (CHD) manager 0.263 (mame0263)
Output CHD: Star Wars - Episode I - Racer (USA).chd
Input file: C:\Users\xxxx\Desktop\chdman\Star Wars - Episode I - Racer (USA).cue
Input tracks: 5
Input length: 122:02:00
Compression: cdlz (CD LZMA), cdzl (CD Deflate), cdf1 (CD FLAC)
Logical size: 1,344,333,888
Error reading input file (C:\Users\xxxx\Desktop\chdman\Star Wars - Episode I - Racer (USA) (Track 4).bin)'
exception occurred: std::exception
Error during compression: Input/output error

Additional details

No response

[987123879113]

Looks like it broke with b75b8d8.

Someone made a comment in the related issue last month about the same problem it seems. #11903

[987123879113]

The exact cause seems to be this code here.

mame/src/lib/util/cdrom.cpp

Lines 2889 to 2905 in 1615b85

	/*
	* Special handling for TYPE_III_SPLIT, pregap in last track contains 75 frames audio and 150 frames data
	*/
	if (disc_pattern == TYPE_III_SPLIT)
	{
	assert(outtoc.tracks[outtoc.numtrks-1].pregap == 225);
	// grow the AUDIO track into DATA track by 75 frames as per Pattern III
	outtoc.tracks[outtoc.numtrks-2].frames += 225;
	outtoc.tracks[outtoc.numtrks-2].padframes += 150;
	outinfo.track[outtoc.numtrks-2].offset = 150 * (outtoc.tracks[outtoc.numtrks-2].datasize+outtoc.tracks[outtoc.numtrks-2].subsize);
	outtoc.tracks[outtoc.numtrks-2].splitframes = 75;
	// skip the pregap when reading the DATA track
	outtoc.tracks[outtoc.numtrks-1].frames -= 225;
	outinfo.track[outtoc.numtrks-1].offset += 225 * (outtoc.tracks[outtoc.numtrks-1].datasize+outtoc.tracks[outtoc.numtrks-1].subsize);
	}

trk 1: 603 frames @ offset 0, pad=0, split=0, area=0, phys=0, pregap=0, pgtype=0, idx0=0, idx1=0, (true 603)
trk 2: 44397 frames @ offset 0, pad=43721, split=0, area=0, phys=603, pregap=150, pgtype=7, idx0=0, idx1=150, (true 676)
trk 3: 311304 frames @ offset 0, pad=0, split=0, area=1, phys=45000, pregap=0, pgtype=0, idx0=0, idx1=0, (true 311304)
trk 4: 751 frames @ offset 352800, pad=150, split=75, area=1, phys=356304, pregap=150, pgtype=7, idx0=0, idx1=150, (true 601)
trk 5: 192095 frames @ offset 529200, pad=0, split=0, area=1, phys=357055, pregap=225, pgtype=1, idx0=0, idx1=225, (true 192095)

It's setting the offset values for tracks 4 and 5 to non-zero values, so when it tries to read track 4 it ends up eventually seeking to the end of the file and ends up reading 0 bytes resulting in the "error reading input file" message.

mame/src/tools/chdman.cpp

Lines 454 to 463 in 1615b85

	std::error_condition err = m_file->seek(
	(src_frame_start >= split_track_start)
	? src_frame_start - split_track_start
	: src_frame_start,
	SEEK_SET);
	std::size_t count = 0;
	if (!err)
	std::tie(err, count) = read(*m_file, dest, bytesperframe);
	if (err || (count != bytesperframe))
	report_error(1, "Error reading input file (%s)'", m_lastfile);

Maybe @rb6502 will know how to handle this case properly? I don't know much about Dreamcast stuff so I don't know why this code exists and what could break by removing it.

[rb6502]

bin/cue support for GD-ROM discs came from external patches, and as was noted this specific regression was introduced by @alucryd so they would be the best suited to address it.

[alucryd]

I would not, as I stated when submitting the patch, I don't speak C++ and I barely understood what I was doing, my limited testing seemed to work so I submitted it for review.

[987123879113]

Should be fixed in #12087.

@alucryd The above PR should also fix the issue you were trying to fix in the previous PR as well. Would you mind giving it a test just to verify if you get a chance?

[alucryd]

Thanks! Will give it a try later today. I have some oxyromon users I can ask for help as well.