search

Atvaark / BinderTool

Dark Souls II / Dark Souls III / Bloodborne / Elden Ring bdt, bhd, bnd, dcx, tpf, fmg and param unpacking tool
MIT License
310 stars 50 forks source link

problems with .tpf.dcx files in Dark Souls III #40

Closed drywario closed 4 years ago

drywario commented 4 years ago

I am unable to extract the majority of .tpf.dcx files from Dark Souls III's data files. The ones in \parts\ and \map\ are fine, but all files of that type in \menu\ (as well as all subfolders) and \other\ return an error. Here's the error from \menu\01_common.tpf.dcx

Unhandled Exception: System.Exception: Signature was not DCX at BinderTool.Core.Dcx.DcxFile.ReadCommonHeader(BinaryReader reader) at BinderTool.Core.Dcx.DcxFile.Read(Stream inputStream) at BinderTool.Program.UnpackDcxFile(Options options) at BinderTool.Program.Main(String[] args)

I am using BinderTool v0.6-pre4, and an identical error occurs from a previous 0.6 version which I downloaded early in 2019. So either the issue is not new, or I have misconfigured or misused both versions in the same way.

Atvaark commented 4 years ago

See the changelog of the 0.6 versions:

Dark Souls III files are temporarily not completely supported (Use v0.5.2 )

drywario commented 4 years ago

Okay, I've now tested /menu/01_common.tpf.dcx and /other/decaltex.tpf.dcx in v0.5.2 and unfortunately it returns an identical error.

Atvaark commented 4 years ago

Have you re-extracted that .dcx file from the bdt/bnd archive before trying again?

drywario commented 4 years ago

I am actually slightly at a loss here, as I successfully extracted everything from the .bdt files in the past - but now when I attempt it with Data1.bdt in v0.5.2, I get a long series of "Unable to determine the length of file " warnings (each followed with a string of only numbers). After quite a lot of these, it terminates with the following messages:

Unhandled Exception: System.ArgumentException: The output char buffer is too small to contain the decoded characters, encoding 'Unicode' fallback 'System.Text.DecoderReplacementFallback'. Parameter name: chars at System.Text.Encoding.ThrowCharsOverflow() at System.Text.Encoding.ThrowCharsOverflow(DecoderNLS decoder, Boolean nothingDecoded) at System.Text.UnicodeEncoding.GetChars(Byte bytes, Int32 byteCount, Char chars, Int32 charCount, DecoderNLS baseDecoder) at System.Text.DecoderNLS.GetChars(Byte bytes, Int32 byteCount, Char chars, Int32 charCount, Boolean flush) at System.IO.BinaryReader.InternalReadChars(Char[] buffer, Int32 index, Int32 count) at System.IO.BinaryReader.ReadChars(Int32 count) at BinderTool.Program.TryGetSignature(MemoryStream stream, Encoding encoding, Int32 bytesPerChar, Int32 signatureLength, String& signature) at BinderTool.Program.GetDataExtension(MemoryStream data) at BinderTool.Program.UnpackBdtFile(Options options) at BinderTool.Program.Main(String[] args)

drywario commented 4 years ago

I can re-extract the entirety of Data1.bdt with UXM, just running its unpack step without patching anything. The .tpf.dcx files UXM extracted also give me the same "Signature was not DCX" error in v0.5.2.

Atvaark commented 4 years ago

If the beginning of the .dcx file you can't extract doesn't look similar to one you can it's probably an issue with the tool that you used to get that .dcx file. The beginning should have words like "DCX,DCS,DCP,DCA,DFLT". If it's just gibberish I can't fix it.

Can you attach some of these .dcx files?

drywario commented 4 years ago

Hi, you are correct that the DCX header was missing from some of the files. After determining that, it took me a while to figure out how to find the origin of the file corruption. But I got some hashes for the game data files and ran them through a checker, and finally I've found that the root of the problem is missing or incorrect data somewhere in Data1.bdt, which caused some of the files inside it to be corrupted once they were extracted. Sorry for all the trouble, but I'm glad to have it cleared up!