Hacking WBFSSync

[Omega Frost]

@hackotedelaplaque

I will see if i am missing any consideration when interpreting the region data, but by now, it shouldn't interfere with the normal program operation, just download the PAL version for the covers...

About the covers for custom games, the cover is linked to the game code, if the game is recoded then the program will not be able to locate a cover to download, BUT you can "trick" the program if you want:

Open WBFSSync\Covers\2D (Or 3D depends on what mode you are using... or both

) locate the original cover, copy it and rename it with the code of the custom game.

@pccfatman

i separated the name and code textboxes, but the processing code is simple, the only error possibility i can see is if you forgot or erased the separator char '-' between the name and the code, anyway, it's fixed now...

 

[hackotedelaplaqu]

About customs covers : I did exacltly this trick before asking here.
But WBFSSync shows the same cover for all my customs GH games.
Games ID are RGHE50, RGHE55, RGHP53, RGHP55, RGHP58.
For each, I have a custom RGHXXX.png cover but RGHP58.png is used for all of my customs GH games.
I used Title renamer by Nixx (WBFSTool), to change the GameIDs of the isos.

 

[Omega Frost]

Try delete the 'Thumbs' folder inside 'Covers', the program will generate the thumbnails again

 

[hackotedelaplaqu]

That worked ! Thanks !

Alright, now WBFSSync is definitively my favourite WBFS app !

 

[hackotedelaplaqu]

Ok another feedback about regions.
Tatsunoko vs capcom (RF4J08) is shown as a PAL game too, but is NTSC-J.

 

[pccfatman]

Hey Omega Frost,

Here is a small translation issue, not a big deal but I thought you should know. I think this is supposed to say "free of"

 

[hackotedelaplaqu]

OmegaFrost,

Oggzee added Fat32 support to his SdUsbLoaderCfg.
http://gbatemp.net/index.php?s=&showto...t&p=2349572

You should talk to him because it would be nice if you add his tool (*.iso to *.wbfs) as a feature of WBFSSync.

 

[hackotedelaplaqu]

Hi OmegaFrost,

Waiting for the next release since it's the best GUI ever IMHO.
- Region fix
- typo (eg. 147GO "libre" instead of "livre")
- Fat32 support (wbfs_file by oggzee)
- built-in "bunpatcher" support for old backups (wanin beta BackupLauncher).
- CISO support in GUI (not only command line).

With Band Hero and Ghostbusters I have this error on log tab :
"le code d'identification SyncScrubbed est incorrect "System.Byte[]". Also, transfer seems slower.
What does that mean ?

I hope wbfssync isn't discontinued.
Thanks.

 

[Maisto]

Is it possible to ad an function to export an list with the thumbs cover, Title, TitleID, Size IOS/Size WBFS ?

Export to ex. Word and get the same layout as the "game" list in the program. that will be awesome.

 

[Omega Frost]

Sorry if i am taking too long, programming is a hobby for me and i need to make it.... oficial... or rather i'm still trying to enter college and in my country this involves a series of tests for a lot of different institutions split in at least 2 fases each, i really need to take hard on it. And this should take about 2 or 3 months...

But when i return WBFS Engine v3 will come also including native support to multiple extensions and, for the interested developers, full compatibility with System.IO.Stream class

@pccfatman

The "livre(s) de" bug is because i forgot to add this string to the Language System.

@hackotedelaplaque

I'll check these formats when i have some time.
About the "SyncScrub Id Code Incorrect"": It's not an error (assuming it's an ISO file), when you enter a folder the program verify each known file type (Iso and Syncscrub) starting with Syncscrub, if it fails to open as Syncscrub (which is the case) it will try to open as ISO.

The speed vary from game to game so it's hard to predict.

@Maisto

It does include a simplier listing function in the console application, exporting to a plain text file.

 

[Omega Frost]

And the work continues... slowly, i'm just passing to ask to one of the C++ Wii-Geniuses this:

I think i found a bug while running through the H3 Table read in the original code from Waninkoko. Inside the wiidisc.c from source 1.5 from Waninkoko there's this routine:

static void disc_read(wiidisc_t *d,u32 offset, u8 *data, u32 len)
{
ÂÂÂÂÂÂÂÂif(data){
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂint ret=0;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂif(len==0)
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂreturn;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂret = d->read(d->fp,offset,len,data);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂif(ret)
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂwbfs_fatal("error reading disc");
ÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂif(d->sector_usage_table)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂu32 blockno = offset>>13;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂdo
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂd->sector_usage_table[blockno]=1;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂblockno+=1;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ[b]if(len>0x8000)
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂlen-=0x8000;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ}while(len>0x8000);[/b]
ÂÂÂÂÂÂÂÂ}
}

Please look at the Bold lines, if length to read is 0x8000, ok, the block marking goes well, but, if length is larger then:

length = 2 * 0x8000 (for instance, 2 blocks)
-> Marks block 'n'
-> length -= 0x8000
-> out of loop without marking block 'n + 1'

Due to wii sector grouping in wbfs sectors the possible bug didn't show up.




I have also found that the region from 0x48000 to 0x50000 isn't marked also, which contains the region code and the second disc magic. Again the grouping dissolves the bug.

Please could someone confirm this, thank you.

Omega

 

[WiiCrazy]

@OmegaFrost : Yup, there is a bug there.. One should use modulus along with a deterministic for loop or equality can be added into the check such as below...

and it seems extra "if" there is not necessary if "while" is used instead of "do while" construct...

ÂÂÂÂwhile(len>=0x8000)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂd->sector_usage_table[blockno++]=1;
ÂÂÂÂÂÂÂÂlen-=0x8000;
ÂÂÂÂ}
ÂÂÂÂ
ÂÂÂÂ//Check left over bytes
ÂÂÂÂif (len>0) 
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂd->sector_usage_table[blockno++]=1;
ÂÂÂÂ}

by the way, if I had written that code then I would have written that part like this.. much deterministic...

CODEÂÂÂÂ
ÂÂÂÂu32 count = len / 0x8000;
ÂÂÂÂif (len % 0x8000) count++;
ÂÂÂÂu32 lastBlock = blockno+count;
ÂÂÂÂ
ÂÂÂÂfor (;blocknosector_usage_table[blockno]=1;
ÂÂÂÂ}

 

[Wiimm]

In my very first code view I marked this function for a review for 2 reasons:

1.) The last loop looks faulty (I confirm you)

2.) if len==0
2a) and data != 0, no block is marked
2b) and data == 0, 1 block is marked.

My fast fix for both:
CODEÂÂÂÂif( len && d->sector_usage_table )
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂu32 blockno = offset>>13;
ÂÂÂÂÂÂÂÂfor(;
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂd->sector_usage_table[blockno] = 1;
ÂÂÂÂÂÂÂÂÂÂÂÂif ( len

 

[Wiimm]

There is a third bug in it: if offset is not at block boundary 1 block to less is marked (perhaps, it never happens):

CODEÂÂÂÂif ( len && d->sector_usage_table )
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂu32 blocknoÂÂÂÂ= offset >> 13;
ÂÂÂÂÂÂÂÂu32 last_block = offset + len - 1 >> 13;
ÂÂÂÂÂÂÂÂwhile ( blockno sector_usage_table[blockno++] = 1;
ÂÂÂÂ}
And again: It's a fast fix (written down while thinking) so please confirm the code.

 

[Omega Frost]

@Wiimm

I agree, but this is the last of a chain of routines that aligns the read to the sector boundaries

 

[Omega Frost]

Here is the code i am using for this, in C#:

private void MarkUsedSectors(ref BUILD_DATA data, long offset, long length)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂint block = (int)(offset / 0x8000);
ÂÂÂÂÂÂÂÂÂÂÂÂlength += (offset % 0x8000);

ÂÂÂÂÂÂÂÂÂÂÂÂwhile (length > 0)
ÂÂÂÂÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂdata.WiiSectorUsage[block++] = true;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂlength -= 0x8000;
ÂÂÂÂÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂ}

 

[Wiimm]

My bug fix is wrong, because real_offset = offset*4.

@Omega:
Is your offset a byte offset or also a U32-Offset?

 

[Omega Frost]

@Wiimm

Yes, all offsets in the Wii Disc are of type u32 offset

 

[Wiimm]

@Omega:
OK.
I only asked because I assumed that 'long' only a 32 bit integer.

 

[hackotedelaplaqu]

New release today.
A lot of fixes.
Thanks Omega Frost.