xma_parse givng "skip bits" error for unknown reason? by placedo at 1:52 PM EDT on May 3, 2010
i've done loads of files using xma_parse/xma_test to transform multichannel xma2 into xma1 files but for some reason i'm getting error's with this one & i can't work out why as it looks like i have the correct settings but i obviously don't, can anyone tell me where i'm going wrong?

this is the file
http://www.megaupload.com/?d=95HACN02

& it contains 8 tracks (4 stereo) & i'm using the following commands & only one of them (track 3 (5/6)) comes out correctly, the other's have error's with skipping bytes issues?

xma_test dataheaderless.fsb -o 0 -b 8000 -r output1
xma_test dataheaderless.fsb -o 800 -b 8000 -r output2
xma_test dataheaderless.fsb -o 1000 -b 8000 -r output3
xma_test dataheaderless.fsb -o 1800 -b 8000 -r output4

& i get the following reports on them

xma_test dataheaderless.fsb -o 0 -b 8000 -r output1
filename: dataheaderless.fsb
version: XMA2
offset: 0
block size: 8000
data size: 14a2000
rebuild output filename: output1
------------------
Parse error: skip bits (3933) did not match previous frame overflow (425)



xma_test dataheaderless.fsb -o 800 -b 8000 -r output2
filename: dataheaderless.fsb
version: XMA2
offset: 800
block size: 8000
data size: 14a1800
rebuild output filename: output2
------------------
Parse error: skip bits (26176) did not match previous frame overflow (830)



xma_test dataheaderless.fsb -o 1000 -b 8000 -r output3
filename: dataheaderless.fsb
version: XMA2
offset: 1000
block size: 8000
data size: 14a1000
rebuild output filename: output3
------------------



xma_test dataheaderless.fsb -o 1800 -b 8000 -r output4
filename: dataheaderless.fsb
version: XMA2
offset: 1800
block size: 8000
data size: 14a0800
rebuild output filename: output4
------------------
Parse error: unexpected "frame sync" 53d2



If anyone can help, it would be much appreciated :)

edited 2:21 PM EDT May 3, 2010
by hcs at 2:53 PM EDT on May 3, 2010
It looks like there's a bad stretch of data at least from 0x136C552 to 0x13704FF. It repeats the same 26 bytes for over 32 blocks, there's no way this could be valid XMA. It's probably a big string of zeros decrypted by a 26 byte key. You might want to check if the original rip was error-free.
by placedo at 3:39 PM EDT on May 3, 2010
thanks for the quick reply, i tried with two different prog's for decrypting the original file, your one (decfsb) & another called "XENFinal" but both gave the same decrypted file.

here's the original file before decrypting

http://www.megaupload.com/?d=URR1BDBC

when i decrypt the files, i always check a portion of the first load of the file to see if there's a repeating pattern of "Y" characters & if the header & filename in the header are correct, i've always assumed this meant it decrypted successfully.

The password i use on the encrypted file above is:

"da 82 20 cd fe 42 74 28 b8 f8 60 2c 2d b2 08 e8 78 18 54 b1 b0 7c 53 85 15 93"

is this right?

& many thanks for the help, been racking my brains with this one!
by hcs at 4:25 PM EDT on May 3, 2010
Yeah, it looks like that original file is corrupted from 0x136D000-0x1371000, there's a few bytes of junk then a bunch of FFs. Try ripping it again, or getting it from another source.
by placedo at 6:11 PM EDT on May 3, 2010
thanks for the help, i re-sourced the file but get the exact same results, i'll try & get a completely different source of the file to see if the results are different & post back here with results :)
by placedo at 2:10 PM EDT on May 4, 2010
just checked another version of the file & got the same results?

there were 3 files associated with this file & the other 2 had passwords that consisted of 31 keys, but this one only has 26 keys so is it possible there's a 5 key digit i'm missing from this file do you know?
by hcs at 2:40 PM EDT on May 4, 2010
The key looks perfectly fine, there was just a bad read from the disc, it happens. Are you sure the other rip you got was from another source? Try finding one from a different release group. Make some noise so people know this one is corrupt, although I suppose it's possible that it's corrupt on the master it doesn't seem likely.
by Surda at 2:56 PM EDT on May 20, 2010
Hello, I am having the same problem.

Only it's highly unlikely that it's a bad rip.

All the 2 channel XMA rips fine. All the 6 channel XMA2 gives this error. I uploaded a file containing 7 of the problem files here:
http://www.mediafire.com/?jm4d4cwnd2f

It might be might fault as this is my first time with XMA files, any help would be appreciated.

Thanks.
by hcs at 12:33 PM EDT on May 21, 2010
Remember, the parser is just a parser, the "skip bits" error is a generic parse error, so this is not necesarily a related problem at all.
As it turns out, your problem is that the block size is 0x10000 instead of the default 0x8000. Add -b 10000 to the command line and you should be fine. And remember, the three streams start at 0x58, 0x858, and 0x1058.
by placedo at 2:43 PM EDT on June 2, 2010
forgot to update on mine & yep, hcs, you were absolutely correct, it was the source i got it from as tried another & it was perfect without any errors, you really are a godsend with these tools, & am so happy to know of this place :)


Go to Page 0

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source