@sonik you are reading my thoughts, I have long wanted to suggest switching to gdi for GDMENU
this will allow you to easily change themes and you can create a combined GDMENU + codebreaker image
GDMENU mount low density as directory cd, high density as directory gd
list.ini find only in cd
As long as some zero padding is made in advance, there should be no need to move the tracks around. Just rebuild the wanted track and merge the TOC, or directly edit track03 TOC to inject the new file size.Menu worked with list in track01! Yay!
When updating track01 the start address still needs to be updated in the gdi file right?
Used track03.iso from gdiopt.exe or orignal track03.iso if it was tiny.
GET!! Colonies
Hello Kitty - Magical Block
Hydra Castle Labyrinth (Homebrew)
Super Runabout - San Francisco Edition
Who Wants to Beat Up a Millionaire
Added buffer 30,720 bytes long to the end of track03.iso
4X4 EVO Revival
Defense Commander (Homebrew)
Floigan Bros
Ooga Booga
Puzzle Bobble 4
Resident Evil 2 - Disc 1
Resident Evil 2 - Disc 2
Shinseiki Evangelion Typing E-Keikaku
SnoCross - Championship Racing
Taxi 2 - The Game
HL 007 GOLDENEYE (Homebrew)
HL BLACK OPS (Homebrew)
HL COUNTER-STRIKE (Homebrew)
HL GRUNT (Homebrew)
HL GUNMAN CHRONICLES (Homebrew)
HL OPPOSING FORCES (Homebrew)
HL PARANOIA (Homebrew)
HL THEY HUNGER (Homebrew)
HL USS DARKSTAR (Homebrew)
Data actually removed, something goes wrong here and 2k of data gets wiped from the end of track03.
SILENT SCOPE (2KB)
https://imgur.com/Jyd0UfH
https://drive.google.com/file/d/1iACpnh7eZ97d-7HQiPBU8Lyx-zBaYYaT/view?usp=sharing
So you'd like track03 to be at least 16 sectors long? It should already be the case. Or do you want to pas track03 with 16 sectors worth of 0x00s?I learned pretty fast that simply slamming some 0s at the end of track03 breaks alot of stuff.
ODE wouldn't see the images as games and GDMENU refused to shrink iso edited this way.
So I took RE2, and replaced a 30,720 byte long block of 0s with 1s, then shrunk it, took the shrunk track03 and replaced the 1s with 0s.
https://imgur.com/Jyd0UfH
This now works fine on emulators and GDemu, saving around 240mb.
Is there an easier way about it? I noticed the GDI didn't change between my 2 builds.
How hard would it be to set GDShrink to leave more padding at the end of track03 in general?
For what its worth something like 30720 to every track03 as a safety net seems like a viable option.
https://drive.google.com/file/d/1iACpnh7eZ97d-7HQiPBU8Lyx-zBaYYaT/view?usp=sharing
So you'd like track03 to be at least 16 sectors long? It should already be the case. Or do you want to pas track03 with 16 sectors worth of 0x00s?
It shouldn't be hard at all to do that in GDIShrink.
# 4- We copy the relevent data from input tracks to output tracks
# *** THIS IS WHERE THE SHRINKING REALLY HAPPENS ***
# TRACK03
with ISO9660(itracks) as gdi, open(otracks[2]['filename'], 'wb') as ofile:
gdifile = gdi._gdifile
begin_offset = otracks[2]['lba']*2048
length = last_toc_sector*2048 - begin_offset
gdifile.seek(begin_offset)
_copy_buffered(gdifile, ofile, length=length)
I'm a little confused about your method. What is GDmemu shrink? I don't know that. Do you mean GDIShrink from GDItools?OK I managed to figure out a way to brute force cos I couldnt wait.
(Im only using gdiopt.exe to consolidate data and make it easier for me to have a free 30720 block to replace during tests)
Two more tests.
DRACONUS - CULT OF THE WYRM
Tosec release gdiopt.exe - Nulled the end random data to test if the game needed it. Booted but is still a large 45mb track. So that confirms there's nothing wrong with the shrink algorithm and that the game doesnt need the repeating data that GDMenu wipes.
But does it need a huge 45mb 0x00 buffer?? Or can we get away with a 30720 byte one?
DRACONUS - CULT OF THE WYRM
Tosec release gdiopt.exe - Took track 03 and replaced 30720 bytes after the last "real" block of data because I knew this shouldnt get wiped, put thru GDmenu shrink, and yep my random data was still there with the track ending exactly on it. Turned it back to 0s so I had a nice 30720 buffer after the last real block of data. BOOTS!
Im really starting to think padding every track03.iso after the last bit of data by an extra 30720 or more or whatever is a good number (yet to determine) would make compatibility skyrocket.
I only chose 30720 because it was over the minimum the most problematic game gave me (around 14000) and was divisible by 512 and 2048 so i guessed it was 2048 mode friendly.
Im have 0 clue when it comes to math and ISO standards but is 30720/2048=15 what you would call 15 sectors?
The reason this title jumped out at me I think is because it was one of a few that refused to compress to CHD, resulting in a tiny file, but after applying my fix it now compress fine.
I had a look at editing gditools.py but got stuck in a wormhole...
Code:# 4- We copy the relevent data from input tracks to output tracks # *** THIS IS WHERE THE SHRINKING REALLY HAPPENS *** # TRACK03 with ISO9660(itracks) as gdi, open(otracks[2]['filename'], 'wb') as ofile: gdifile = gdi._gdifile begin_offset = otracks[2]['lba']*2048 length = last_toc_sector*2048 - begin_offset gdifile.seek(begin_offset) _copy_buffered(gdifile, ofile, length=length)
'Barry: What? What is this...?
'Jill: What is it?
'Barry: A CUE!
'Barry: Jill, see if you can't find any other CUES, I'll be examining this...
'Barry: I hope this is not a BIN file!
Alright I'll try to look into this. Normally, GDItools should ensure that only 0x00s are removed.Bug? (unsure)
Description of behaviour
Track03 of DRACONUS - CULT OF THE WYRM has 2 blocks of repeating data at the end of the file that get removed when shrinking with GDItools.
Any attempt to add random data to the leading or trailing edges of these blocks is also destroyed.
It seems anything after a certain offset gets wiped regardless of the datas structure.
Expected behaviour
GDI tools should keep these 2 blocks.
git clone https://git.code.sf.net/p/dcisotools/code dcisotools-code