I've already posted this on the layouts forum but that place seems a bit abandoned.
(Copy&paste)
Hi there, I've made a patch for the original xdvdfs_maker (2.1) to include cross-linked files, much like Qwix does but with the benefits of layout files.
I made this in order to produce a decent copy of Ninja Gaiden Black, with no dummies or missing files, it worked just fine so I guess it should work with other games (only tested it with NGB).
To add a linked file you need to manually edit the .LYT file and add/modify a line so it looks like this:
L,<filename>,<real file>
This will create a "virtual" file <filename> which will be cross-linked to the specified <real file>.
Please let me know if anyone's interested. Will upload the source code too, even if it's a bit embarassing and/or messy (I'm not the best coder around)
Just tell me please where to upload it since I'm new(bie) here.

Also, if there's some other program which already does this, please let me know.

Nice to see someone working on XDVDFS, but I don't really understand why you've done this. The whole point of using layout files is to duplicate as far as possible the original layout to quicken loading speeds. Original games may have the same file in multiple places on the disk to save the drive head going back and forth too much.

Hiya. I did this because I wanted to burn Ninja Gaiden Black to a dvd5. The only options were to delete some japanese (or english) movie files or replace them with dummy files. I didn't like those options so I crosslinked the movie files with Qwix. The resulting (alphabetical-ordered) ISO gave me random Scratched-disc screens.
That's why I patched the program. I'm not suggesting it's a good idea to crosslink many files, or doing it at all (specially because many games will fit on a dvd5) but in the case of NGB, being movie files and not a lot of them, I don't see the problem because in-game files are layout-optimized anyway.
I'm not sure if this can be done with other "big" games, probably The Warriors, but it could be used IE to relink language-specific audio files resulting in smaller games for multi-game discs. Or, as in NGB, delete trailer videos and relink them to another video.
Or you could just delete them.... I just don't like that option.
Anyway, if original games happen to have the same file in multiple places, it doesn't matter because the cross-linking is done by editing the layout file, the program won't search for duplicate files like Qwix does, and duplicate files will be respected.

Ok, I understand now. I wouldn't like to see MooGUI or something else automatically searching for and cross-linking files, though, as I think too many people might tick that option without realising that it might in fact make things worse in terms of loading time often! But manually linking files is fine, I reckon.

Regarding getting games to fit on a DVD5, I'd rather see XDVDFS tools upgraded to support DVD9.

Actually XDVDFSMaker 2.2l Does support DVD9. But I'm not sure if MooGUI does though.

I'm a big fan of the XDVDFS system. I wouldn't mind playing around with this a bit.
You should PM Vood, as he's running the official Layouts site. I'm sure he'd be happy to add your patch to the downloads.

http://forums.xbox-scene.com/index.php?showuser=98950

I may be really wrong here (correct me if I am), but version 2.2l doesn't properly support DL dvds, I'm not sure but I think it changes the size check so it can create ISOs bigger than 4.7GB (single-layer) and remove the outer padding if it's bigger. To really support DL you need to introduce a layer break, make sure layer 2 isn't bigger than layer 1, also consider the padding space, etc.

This all sounds interesting to me, I think I'll start working on that next



Thank you, I'll do that. Just let me apply some of the v2.2l fixes before sending it to him, my patch is based on 2.1 and I wouldn't like to see old bugs reappearing. I didn't know the source for v2.2l was released when I started to work on this.

I've uploaded this new version to the layouts site if anyone wants to try it
http://layouts.xbox-scene.com

(copied from the txt file)
This is basically the same as v2.2 lite by xbwin, with added support for cross-linked files.
+ You can create an ISO without a layout file again, -ordercreate is back as well
+ Hopefully fixed the block size error, as well as the infinite sized dvd images
+ Cross-linking of files. Shouldn't be needed for most users.

Very nice.
Thanks for your contribution to the XDVDFS system. This should prove to be most useful indeed.
I'll run some experiments with this, and post some feedback. I suppose the next step would be to get MooGUI updated to support this feature.

With a new wave of renewed vigor in Xbox360 hacking, there's a possibility that the upcoming Qwix 2 might support the .lyt Layout files also for ISO optimization. Only Devenic knows for sure...

Hiya. I'll appreciate your feedback. As for MooGUI I'm not sure it'll be updated to support this change, first let's see if enough people finds it useful, only time (and feedback) will tell.

I really like Qwix (I'm an Avalaunch user), it would be cool if the new version supports layouts... and let's hope xb360 gets hacked soon to encourage the development of more tools!

Talking about the Warriors, has anyone successfully backed it up on a DVD-R Dl ?

yes qwix support would kick ass
take note qwix author

neat! i got "published" in the main page! (of the Layouts site) What can i say? I hope people finds this version useful and not too buggy! anyway the real hard work was already done but hey! it's nice to get some credit!
I'll try to do DL next, right now I can't figure out how to put the layer break in the ISO file (google has been unfriendly this time) maybe do a big 8.5gb file padded with zeroes

Have you tried cdfreaks.com forums ?

Does anyone know what the situation is with Xbox360 disc images and layouts? Are the images that people have already dumped in the same order as the original discs, or are they alphabetical?

It would be nice if the Xbox 360 scene could start from the beginning correctly, with properly layoutted (is that a word?) ISOs.

I believe X360 isos are sector dumped, so they´re already optimezed

Mmmm...Mexico..

Pues en cuanto a dvd-dl, es algo más complicado creo. Lo primero es determinar el sector exacto donde se hace el cambio de capa, y tener en cuenta que ningun fichero quede entre ambas capas.

Pero lo que realmente CloneXB y yo pretendíamos en un principio era replicar las optimizaciones de cambio de capa, de forma que se minimizase el tiempo de acceso en el caso de que el disco original tuviese algún tipo de optimización a este respecto. Para ello pretendíamos simular el espacio gastado por los security placeholders de forma que los ficheros quedaran en su posición original relativa, y de paso aprovechar el padding para moverlo todo hacia los extremos.

Por cierto también has salido en las noticias de xbox-scene.

--------------------------------------------------------------------------------------------------------------------------

About dvd-dl, I think is a bit more complicated. First of all is to check in which exact sector is the layer change done and also keeping in mind no file should remain between both layers.

But what CloneXB and I really pretended was cloning the layer switch optimizations so the access time was decreased just in case the original disc had any kind of layer switch optimization. To achieve that we wanted to simulate the wasted space which the security placeholders use so the files were kept in their original relative position, and btw using padding in order to move everything to the outer part of the disc.

mmmm... España!... creo que este idioma lo domino mejor que el ingles pero por ahora continuare haciendo como si en verdad dominara el ingles
-----
About the layer break the problem is I can't put this info (LB sector) in the ISO file, I need to either write a header file with a standard format (.MDS, maybe .CUE?) containing this info, or inform the user of this number so it's manually fed to dvddecrypter/imgburn/(other?). I think header files are propietary, so they don't have a public definition, for now I'll just output this number.

DL originals tend to have their files around the layer break (I.E. not starting at the first data sector), but since they are recorded (pressed) the other way around (outside to center) would it be right to assume the layer break is near the center and the content is "padded" towards the center?
I'll put things relative to the LB, this will create a sector layout similar to the original, in theory this will recreate any layer switch optimization, but on regular DVDR media the content will be inverse to the original because files will be padded towards the LB which is near the outer edge.
(I'm not good at explaining things I know)
This will be the first version, in the next one i guess i'll have to do something like -opt1, which will move files from layer 0 to 1 and vice-versa, and the files will be padded away from the LB and towards the start of L0 and end of L1.... this is because a DVDR L1 goes from the outer edge to the center, like a XDVD L0 does, so our DVDR L1 will become a "virtual" XDVD L0, and padding away from the LB would cause files to physically be in a position similar to the original, even if it's really on the "wrong" layer, and simulating the original LB near the center. This will produce a sector layout not similar to the original, however if I'm right it should be physically similar and keep any layer switch optimization (only when padded right).
(Once again, sorry... Not good at all at explaining myself)
But first things first, are my assumptions correct? does layer 0 of XDVDs really start at the outer edge? etc.
And... first things first, lemme get back to work on this without the -opt1 stuff

DL originals, are just are single layer disc, layer 0 starts in the inner part of the disc, and it´s read toward the outer part. And then, layer 1 begins in the outer part and it´s read toward the inner part. The files are not around the layer change, and the correct way to pad would be this one.






Keep in mind the file order would be exactly the same if we use the data included on dl layout files. In fact for any dvd reader double layer disc are seen as standart discs, except for the layer switch point which is completly transparent to the system, so that´s how the file would be spread:



(this image doesn´t show the non usable outer part of the disc, nor security placeholders).

As is shown in the first picture, you NEED to know where security placeholders are and their size in order to make a exact double layer backup from an original disc. At the moment, xobx layout dumper is no t able to detect that...and sice is kinda abandoned probably will never, unless someone else makes a new dumper supporting that.



Mmmm....nope, just forget any file order inversing and all that in DL disc, is not needed at all. Remember:

L0: from inner part to the outer part
L1: from outer part to the inner part.

There´s good documentation about all this in the XDK, and also on the original topic in which we discussed the layout file´s theory. Also MooGUI´s included documentation has nice info about Xbox´s disc structure.

Opps, I forgot you probably wont need where security placeholders are, as we have the sector numbers and file sizes of every file, and so, it´s just a matter of keeping the same relation, just as in the first picture.

Hiya. I'm glad I was wrong on this, I've just proved my newbieness by just believing (and mis-understanding) what was said about xbox DVDs being pressed from the edge to the center, and not reading anything else about it. Now I've read the entire original thread, very interesting to see how this project started to grow, and nice work defending your idea!
Thank you for clarifying things

Security placeholders is something i wasn't considering (i thought they were only added to the padding area) but I'll get this info from the sector numbers on the layout just like you said.

Now my dilemma is how to specify where to start the layer break, i dont want to force it to look for a file in sector 1715632 (to allow custom, non-original DL layouts) but rather specify in the layout which file will start layer 1, the best place would be in the layout header i think, maybe as a comment so it still works with actual & older layout-based programs, however it would need manual editing until tools are updated.... my suggested syntax is something like this:

#@LayerBreakFile: /dir/file.ext

The "#@" would mean special data (metadata?) follows, since it starts with # it's ignored in actual programs, it could have other uses like specifying if the iso will be padded or not, and how much to -OEIBuf pad... but that's gonna be in some future release if it's accepted, other syntax could be:

H,LayerBreakFile,/dir/file.ext

The H is for "Header", next is what header info we're talking about, then the actual value

.... Or it doesn't matter as long as it gets the DL stuff done? (opinions, please!)

Wow. I'm glad to see that this project is still going. I thought it had died with the release of 2.2l. I think you guys have done really great jobs with this (I even created a Xbox-Scene account to tell you how great these programs are). I would really like to see this project continue to grow to the point where I no longer need 2 xbox programs installed on my PC anymore (as well as DL support for mooGUI, so I don't have to use command line any more ). I would be willing to help out in any way I can. I am fairly good with C++, so if I could help in programming or debugging, that would be cool. I've always wanted to do some xbox related programming before, I've just never had a good reason before. Just e-mail me (chris.usher@gmail.com) if you'd like any help (especially cause I got spring break to waste for a week now ). I would also like to know what I need to build the source from the layout site (just a compiler, or XDK, or something else?). Thanks, and please let me know if I can help in anyway.

Edit: Oh yeah I got msn messenger & google talk too, I use the same e-mail for both of those too. Whenever I'm online, I'll be findable there.

I think there´s no way to specify where the DL break is set on a standart iso file, that´s probably the reason because of DVDDecrypter let you to specify an exact sector for layer break
So the way to make this would be just generate the DL iso using relative positions to the original disc, and then (or after padding if it is used) check which sector is the last one in the files included on layer0.
Then you could just simply add the value to the iso name, and prompt for the user to type this number at dvddecrypter layer break sector option.

(btw, I hope you didn´t changed anything problematic on the standart single layer code on xbdvdfs_maker, I mean, if you thought the disc was read backwards, and you modified something according to that, you could have broken something)



XBDVDFS_maker is very easy to compile. In fact it compiles in almost everything, it doesn´t use anything strange. In windows clonexb used visual studio, but, I think it also compiles with gcc, even on linux. As for Mwg, I suggest you to read the included documentation on the xdk, and the original topic to get a nice idea about how really all this works.Then maybe you should contact him to cooperate.

Don't worry, I wasn't sure if i should do it that way, that's why i posted that comment before doing anything.... like i said before, I'm glad i was wrong! my "theory" wouldn't be easy to program i think

However I'm changing some parts of the code so it works wiith DL and pads the areas where security placeholders were so i ask of you to please beta-test it (or alpha-test) because im changing working, tested code with some new untested code

You MUSN´T change the way padding and everything else works on single layer discs unless there are bugs. Emulating the security placeholders it only has sense on double layer discs (in addition to regular padding, as I explain in the picture I posted before). We don´t want to break something that already works fine.

About DL betatesting..., I have no DL burner, and even If I had one, I´m not sure about if I would be brave enough lol.

Alright, so are all of the folders in the source archive one project? Or is each one supposed to be built sepratley (other than the inculde folder, of course). Or do some builds use multiple folders? Which files/directories go into building what programs?

Nevermind, VooD nicely helped me understand how the source files were organized

I won't change the way things work, but since i'm adding new stuff i have to alter what's already there so i have the risk of breaking something, i mean for example i wont get more funny ideas about changing the padding or anything but i may have to change the code that does the padding so the new things work and it may or may not break... of course i do what i can so it doesn't break, but it can happen

I think i've completed a preliminar version, but im ashamed to admit i dont have access to DL media! (did this as a hobby) so I can't really test it, I did the usual test (NinjaGaidenBlack) and it calculated the layer break, calculated and padded the placeholders and made a correct, readable ISO. I will upload it later but it should be noted it's an untested version. Any tests would be good, even a couple of regular dvd5s just to check it still works

I have a couple of blank DVD-R DLs, and a few DVD-RWs (single layer) so I could help test . Unfortunatley, I don't have any games over 4.5 gb to try burning... but I could try burning some single dvd5 images made with the new version on RW discs to make sure you didn't break anything (especially not the planet ). If I can help, just let me know.

Something you can try meanwhile is testing if the files are in the expected sectors using xiso.

Hiya, I've uploaded the new version to the layouts site (named it 2.3 alpha), right now DLs are done by adding this line somewhere in the layout file:
#@LayerBreakFile,\path\file.ext
Here you write the first file that goes to the second layer, with full path. If this line doesn't exist, the file is calculated by filling the available space on layer0
Also you can add this line:
#@PadSecurityPH
it means "Pad Security Placeholders", if it exists somewhere in the layout then placeholders will be padded so it's more similar to the original. It doesn't have to be a DL game but it makes sense only on DL games. The layout must be the original, if you move some files please use MooGUI or manually change file sectors to zero, otherwise things can get messy (only if you use this option)

Also I've added a program parameter "-simulate" if specified, it will not output any file (still need to specify output file however) and only calculates file placement and stuff, and it will cough some extra info when doing calculations, mostly sector numbers and data sizes, i had this for my own testing but i left it there...

When it finishes doing the iso, it will tell you where the layer break is:
Layer Break (Sectors in L0): 112233
You need to write this number on DVDDecrypter or ImgBurn, go to the settings, "Write" tab (or Iso Write), in the Layer Break option select User Specified, then in "Sectors in L0" write the number. Obviously, you need to do this before burning! when you finish burning, reset it to "Calculate Optimal" or whatever info you had. If you always use -pad and the same number of OEIBuf, then most likely the number returned will always be the same.

Thank you, if you could burn a couple of images on RWs and try them on your xbox, that will be great... try using the -pad and -OEIBuf options, those are what im worried about the most. Also if you get a DL game and can successfully burn it please let us know!


Tested this already, however I used "C-Xbox tool"

Mmmmm...so why did you make that option? Xbox layout dumper already dumps this on DL discs:

#
# <<<<< LAYER 1 BEGINS HERE >>>>>
#

So you just have to take a look at which sector starts the first file after that, and substract 1 to get the layer break point. It just create confussion to the user.

Also, you shouldn´t use the lyt file to add options like #@PadSecurityPH, I think is better let the use the final decission on the command line, or just make it default for DL disc.

The layer 1 marker as it is now is made to make the LYT more human-readable, I don't think it was intended to be read by any text parser, I can do that but it's not the most optimal way to do it, also if you use mooGUI to edit the layout, the markers go away, we need a more solid way to mark the layer break now that it is becoming a reality, that's why i thought of this "special comment", either that or using another letter in the layout like "B" for Break. But yeh you're right, I'll just look for the position of this marker, no need to specify the file in the LYT, I was using a "Header data" approach. For now I'll look for both the actual "LAYER 1 BEGINS HERE" text and this text "#@LayerBreak" which is a suggested syntax, aimed more to other developers than regular users

By the way, you don't substract 1 to get the LB as dvd decrypter suggest, LB sector# is = to the number of sectors in layer0


Alright I'll do that. But i won't make it default for DL, just in case someone wants to do a custom DL layout, maybe a multi-game disc with a game on each layer.... Dunno if it's a good idea but that should be up to the user

I tried using the 2.3 alpha to make an ISO for a game that worked before (single layer). After I burned it, I popped it in and... it didn't read. I tried again on a brand new spankin' disc and... no read. Luckily, they are both RWs so I have two blank DVDs instead of two coasters now. Can anyone verify it doesn't work?

The point is, the user shouldn´t edit the layout in moogui for DL disc, as he is supposed to want the best and more precise clone of the original disc.


Cough cough....that exactly what you get if you substract 1 to the sector in which begins the first file of layer 1.



The main reason for making a DL backup is to keep every possible optimization, and data, so if you don´t use the security placeholder emulation, double layer switch optimization would dissapear...so, let it default

Just my opionions on it:
-The layout files should not be any different, to ensure that all the currently existing layout files stay valid without having to be edited unless:
A. The standard for the layout file is changed to make the layer start line different, and the layout dumper is modified to reflect the new standard
and
B. Someone make a program that will go through any existing layout files and cahnge them to the new standard format
and
C. Someone wants to volunteer to go on the layout site and or possibly download each of the files and run the mentioned program on themthen re-upload them all

-Dual layer games should by default not do the... Ahhh too compilcated to say, just what VooD said at the bottom of his last post. One of the options should be to do it that way.

Hey, what happened to -opt1 and -opt2? Is mooGUI the only way to do what these do? If so, I think it should be added back to XDVDFS.

Hmm... one of the same discs that didn't work yesterday did work today... I'll try a few more things to test it out. Oh yeah, what would happen if I made an image from a 2 layer game smaller than 4.5 gb? Would the layers in the layout be ignored (I didn't add the @LayerBreak btw) and it would just make a normal single layer image, with the layer in the wrong order?

Hmm... one of the same discs that didn't work yesterday did work today... I'll try a few more things to test it out. Oh yeah, what would happen if I made an image from a 2 layer game smaller than 4.5 gb? Would the layers in the layout be ignored (I didn't add the @LayerBreak btw) and it would just make a normal single layer image, with the layer in the wrong order?

Aye aye sir, Cap'n, sir default it is then...
have you discussed layer switch optimization on this forum? i've read the entire original topic and it's not discussed much, and the search brings me back to this topic


Yeah I'm trying to keep it usable with actual layouts, but i still think the way they mark the beginning of second layer is kinda weak, that's why i was suggesting the "#@LayerBreak" syntax for a new possible standard (and I'm leaving it there even if it goes ignored!! until someone properly defines the new standard).
I'll add the option to disable padding, but it will be enabled by default on original DL layouts


*I like MooGUI* ermmm.... VooD? Do you think i should put those back?


Writable media not working properly on xbox isn't a strange thing, just to be sure please try to burn an iso generated by an older version on the same RW. Thank you for your feedback
I did this, i generated two images from the same layout, one using the old version and one with the new one, then i did a binary comparision (with ms-dos fc /b, which is Slow), and it had a difference, when I checked what was the difference it turned out it was the ISO creation date/time (added by xbwin) but otherwise there were no differences.... then i did the same test with -pad, and again with -pad and -OEIBuf 2048, no differences... I can (almost) assure you dvd5 games will work as before

And you mentioned something which i had overlooked completely... DL games on a dvd5! The version you have right now will work as before if you don't add the LayerBreakFile thing (something im gonna change next) so no problem, -pad and -oeibuf should work.... But! if it looks for the "layer 1 starts here" text, all existing DL layouts will be treated precisely as DL even if they fit on a dvd5! maybe you wont have problems if you don't use -pad, but if you do you'll end up with a file bigger than a dvd5. I can add a switch to force it to make a dvd5, much like it worked before xbwin's version. Comments on this?

The new version seems to work fine for single layer games (i.e. Dynasty Warriors 4), and for dual layer games that fit on a single layer disc (i.e. Tenchu Return From Darkness) it turns it into an image for a single layer disc, like you said it would. I haven't tried a disc with the #@LayerBreakFile yet, I think I will see if they have DVD-RW DL at Office-Max first to test (dont wan't waste a DL dvd if it's not gonna work).
So if there is a game over the size of a dvd5 that doesn't have that line then the space will just be padded in layer 0 to fill up the dvd? Is it at the beginning or end of the layer?
Also, for future versions, I think it should follow this (just my opionion):
Have the following options (or something similar):
-h : Disaplays help text.
-pad : Pads the image to fill entire disc.
-OEIBuf [n] : Will leave a gap of [n] Mega Bytes near the outside edge of the disc when padding a image. This option can be used to avoid writing to areas of imperfections sometimes found near the outside of cheaper discs.
-order [Filename] : Same as now
-ordercreate [Filename] : Same as now
-SL : Will create a single layer image for a dual-layer game if the game can fit on a single layer disc.

General program flow (doesn't cover everything at all, not even close):
-If -ordercreate flag is used, create layout file (and end program, if thats what it does now).
-Check the size of the game
-If it can't fit on a single layer disc:
---Path A.
---If the -SL flag was used:
-----Report error to user that the game cannot fit on a single-layer disc. (End program maybe?)
---If (gameSize + OEIBuf > dualLayerSize)
-----Report error to user that the image cannot fit on a dual-layer disc.
-----If (OEIBuf > 0)
-------Tell user to try lowering OEIBuf.
-----End program.
---If -order flag was used:
-----If valid layout w/ both layers:
-------Call BuildDualLayerImage function thingy . End program.
-----Otherwise
-------Report error to user that layout is invalid or doesn't match game. End program.
---Build image without using layout, using padding if -pad is used. End program.
-Otherwise
---If the -order flag was used
-----If the layout file is valid
-------If there are two layers
---------If -SL flag is not used
-----------Go to path A.
---------Otherwise
-----------If -opt1 and -opt2 flags are re-implemeted, they work here.
-------Otherwise
---------If -SL flag is used
-----------Give error about single layer game not using -SL
-----Otherwise
-------Give error etc.
---Path B
---If (gameSize + OEIBuf > singleLayerSize)
-----Tell user to try lowering OEIBuf so it can fit on a single disc and end program.
---Create single layer image using whatever from earlier (padding, buffer, layout, etc.)
-ALL DONE!

Kinda messy.
Oh well.
Its jsut my opinion (which is correct, btw ). Follow whatever parts of it you feel like.
If you would like any help coding or for anything else, just let me know.

The -opt1/2 settings for XDVDFS reorder the files during the creation of the ISO, taking a little extra time as the ISO maker looks for the "Layer 0 or 1 Begins Here" marks in the layout file. MooGUI has the option to layer optimize within the program, however doing so doesn't simply add the -opt switch to the output batch file. Instead it completely reorders the layout file itself, and removes the layout break marks after completion. This method is faster and more dependable, and makes the XDVDFS ability redundant.

????????????????
Better we forget all that. Anyway, I know about some other important project, and it´ll keep the same format. So xbdvdfs_maker lyt format should remain untouched.



It was removed, in first xbwin fixed version. And it really did have sense, as MooGUI already includes its own routines, and much more. Also nobody uses these tools from commandline other than "we" developers.


It wasn´t discussed on the forum, but CloneXB and I talked a lot about it directly.
Probably, xbdvdfs_maker should remain as faithfull to the original as possible to keep compatibility with moogui. So, DL disc should be a switch, and not default, in case the data fits in a dvd5.

Finally about all that IG Chris program flow, as I said previously, the program should remain as similar to the previous versions as possible to keep compatibilty with MooGUI, also very few people will every use it from commandline, so it would be better to implement all that warnings and so (MooGUI already have a lot of warnings, and prompts) in the frontend, MooGUI, or a new custom one . Tough I believe it would be pretty hard to surpass MooGUI excellent design.

Actually, I use the commandline tools as I use Linux, and there is no Linux MooGUI equivalent.


That's good to hear. I think the Xbox scene only started making 'wrong' ISOs in the first place because of the way it originally got access to the files on disc at the file/directory level (in the very early days), rather than the sector-level. PlayStation, PS2, Dreamcast and GameCube scenes started at a sector level from scratch, as far as I know, so they never had the problems we're having.

Yes, I agree that MooGUI should cover as much as possible, I was just pointing out a way it could be implemeted in XDVDFS. But now that you mention it, I think MooGUI would be much better to take care of the Dual-Layer games that can fit on Single Layer discs problem. Changing something in the layout optimization to not be able to to the layer combining if the game is over the size of a single layer disc would fix that, adding a couple other notifications etc. Speaking of which, is the MooGUI source code available?
Thinking about it though, XDVDFS should just check the layout to see if it's dual-layer or not, (so people can just use MooGUI to merge the layers inito a new layout if needed (like you can do now)), and then all that needs to change is the Dual-Layer image making from the current layout files (looks like VooD wants the same standards for layout files). I might be able to test the DL feature for 2.3 alpha today, I'll let you know how it goes.

I'm so pissed at myself for bothering to type that flow thing, and then realize a little later that it was totally pointless.

Edit: Hmm... MooGUI is windows only, eh? Maybe I'll start an SDL port of it if anyone else thinks it's a good idea. Comments on this?

Nope. But who knows...maybe Moobar is finally ready to release the source or to continue working

Moogui already prompt you to move <4.3gb DL games data in a single layer.


An SDL port? I tought there wasn´t non-gaming related apps for SDL. You would have to create a whole GUI or create some kind of wrapper and also porting from Visual Basic to C.
Maybe is easier using Wine for linux people.

mmmmm.... just uploaded a new version, 2.3 alpha2, and deleted the old one... (too tired to write anymore)
anyway after writing & removing some useless code here's how things are:
+ Will work with current LYT format, will look for this text to know where to change layers:
# <<<<< LAYER 1 BEGINS HERE >>>>>
+ new -DL parameter to work in double layer "mode". Otherwise it should work just as before
+ new -nopadSPH (Do not pad Security Placeholders) parameter. Works only with DL. By default, dvd5 images are not padded and DL images are.
+ added "-OEIBuf XDVD" this is for evaluation purpose, it will use the original xdvd layer size of 1715632 sectors, use xdvdfs_dumper with the generated image, the resulting layout should be the same as the original (unless you don't use -pad or use -nopadSPH etc.)
+ kept "undocumented" -simulate option
+ will return "Sectors in L0" value at the end, for dvd decrypter / imgburn / (other?). I believe this works only on DL DVD+R, not -R, according to the author of dvd decrypter

mmmm... that's all for now... buenas noches (i want spring break!!)

Looks good...now we need a brave guy with a dvd9...

Looks pretty good mwg40 (if it works, that is). Nice work! I have a couple of DVD9s, however the only DL game I have (that is actually DL size, that is) is Jade Empire, which I have already burned, so unless I happen to find somewhere with DL RWs, then I guess tomorrow I will go to blockbuster, and rent Ninja Gaiden (I only played it before my xbox was even modded, so I never ripped it) and I guess I will try that out.

As for the SDL GUI for XDVDFS usage, I still think that it would be a pretty good idea if the MooGUI source is released or if someone would help me with a couple parts (i.e. the actual making of the batch file). I dug through my old e-mails and found a version of my old SDL engine, and I am almost done fixing it up. After that, I will start making a window node class, and hopefully it wont take too long before I can have a general window creation thing ready . If only it were that easy... Oh well, I'm having fun working on it, at least.

well ya know, it sucks not being this brave guy! i'd have liked to be the first to see it actually working.

By the way, what was this "other important project" you mentioned some posts ago?


Thanx!
I read on doom9.org news, the specification for DL RWs was just defined so those don't exist yet... bad thing!

some people may not know this but some of us actually have fun working on some code!


Now, assuming this version works (it does!!), for the next version i was thinking of adding the option of reading the files directly from another ISO, i think xdvdfs_dumper does something of this and even opens recorded dvds, this would be used to optimize existing isos.... anyone interested?