Driver with Bleem! ?

[Soldiaz]

ups sorry :-) im wrong. Of course the dummy will speed up gamespeed, but only if the dummy.dat is burned correctly as the first file, so that the other files are burned after this.
In this case the game data would be shifted towards the middle of the disc and loading time will be limited.

[hrb2k]

i noticed that about -sort option. i made an iso using mkisofs with a sorttxt.txt and then opened the iso in isobuster and the files appeared in alphabeticle(spelling) order, including the lba for each file.

so about the dummy files. if it is named with 3 zeros ahead of it, 000dummy.dat, it will be the first file burned. other game data will come after that. some games have an 0GDTEX.PVR file so its better to name a dummy with 3 zeros.

[Excalibur007]

It seems to me that since using a sort.txt is unreliable, it's better to not even use one if you are going to add a dummy, (I usually name my dummy "000.0" simply for aesthetic reasons). I suppose sort.txt could be useful if you want to just sort the rest of the files, but they still won't be put in the order you dictate with the sort.txt. That is, unless someone knows how to make mkisofs use a sort.txt reliably, which leads me back to the question...

Does anyone know how to make mkisofs accurately sort files?

-Ex

[hrb2k]

i did a search on google and found out that using the -sort option in mkisofs doesn't sort the filenames, but it sorts the way the data is written to the cd image.

i can't copy and paste on DC pw browser, but go to google and type, mkisofs README.sort, then scroll down and click the link to the burnatonce forums. the readme is a .txt attachment.

to sum it up. the command line is correct,

-sort sorttxt.txt

the files in the sorttxt are sorted like so,

filename weight

the higher the weight number, the file will be burned first. the lowest number will be burned last. so in most sorttxt files, the 1st_read.bin has a weight of " 1 ", which means it will it burned last on the disc since it has the lowest weight number. so if a sorttxt looked like,

data/1st_read.bin 1
data/file.1 2
data/file.4 3
data/file.2 4
data/file.3 5
data/000dummy.dat 6

then i will be burned like this, first to last,

000dummy.dat
file.3
file.2
file.4
file.1
1st_read.bin

this is what i get by reading the readme. so maybe we are burning it correctly...???

[hrb2k]

but then again, do the lba's on the discs dictate the data being sorted...??

[Excalibur007]

A sort.txt is supposed to sort the files by where you place them according to your numbers. You "should" be able to even place a higher weighted file at the top of the list and it should be burned first (as long as you give it a higher number), so the actual placement in the list in not what's supposed to matter, but rather the number you give it in the sort.txt.

However, this is not the case. You can have 1256 files in your sort.txt and you can number the 1st_read.bin "1" and the dummy "1256" and the dummy will still end up somewhere toward the middle and the 1st_read.bin will probably end up somewhere toward the beginning, (exactly the opposite of where you placed it).

The way the lba comes into play is this. If you're making a sort.txt using the structure of a CDROM, you "copy tree info to file releative path", and it will save that info in the directory you specify as "filelist.txt". This file has all the lba's of the files. When you run F2S.exe on it, the files will ba placed in order of lba's from the highest to the lowest and numbered from 1 to ???.

It has been my experience as well as the experience of many others, that the -sort option in mkisofs is not reliable. Just do a google search for "mkisofs sort" and see how many results you get that are ppl asking the same question I posed earlier.

Is there a way to make mkisofs sort the files accurately, (meaning the way ACTUALLY DICTATED by the sort.txt)?

-Ex

[Hacker999]

Originally posted by hrb2k
the higher the weight number, the file will be burned first. the lowest number will be burned last. so in most sorttxt files, the 1st_read.bin has a weight of " 1 ", which means it will it burned last on the disc since it has the lowest weight number.

I tried this and it worked. Except I did not use a dummy file since the game loads fast in the order that I put it in. You guys should try it.

And to think, all this time I was trying the complete opposite.

[hrb2k]

you sure it works? does the gd drive go to read something on the outside of the disc right after the sega screen?

[Hacker999]

Yep it definately works. I got KOF 2000 working properly again.

[Excalibur007]

Originally posted by Hacker999
I tried this and it worked. Except I did not use a dummy file since the game loads fast in the order that I put it in. You guys should try it.

And to think, all this time I was trying the complete opposite.

This is how it's "supposed" to work. This is what I've been saying all along. However, it doesn't actually work properly like this. Hacker999, I'm sure it didn't just sort aphabetically, but I doubt it actually sorted it according to the sort.txt. Get a filelist of the new CD and make another sort.txt to see if it matches the one you used to make that CD. I almost garauntee that it's not the same.
Let me know what you find on that.

This brings me back to... is there way to make mkisofs sort files accurately?
I use a sort.txt in my betas of Psilocybin Dreams 2.0. It works much better after being sorted, but it still doesn't sort accurately according to the sort.txt. For example: I have a trial version of MSR (speedster vs vx220) on that disc. I put my own music in there, but to keep the music from skipping, the *.afs file needs to be closer to the outside of the disc. I place it at a value of 1895 out of a total of 3824 files. It's after the midis, mpeg clips, and homebrew binaries, but before the rest of the DPWWW folder. The sound DOES work properly because it DOESN'T get placed too close to the center of the disc like it would if I didn't use a sort.txt, but it DOESN'T place it where I actually dictated. This is just ONE example of how mkisofs doesn't sort accurately.

-Ex

[Hacker999]

Originally posted by Excalibur007
Hacker999, I'm sure it didn't just sort aphabetically, but I doubt it actually sorted it according to the sort.txt. Get a filelist of the new CD and make another sort.txt to see if it matches the one you used to make that CD. I almost garauntee that it's not the same.
Let me know what you find on that.
-Ex [/B]

It almost matches. But all the LBA's are different. Some of the files are exactly where I wanted them to be and others are way off.

[hrb2k]

oh, no. darkfalz sorttxt site is down.