28 replies to this topic

[Argent77]

Interesting.  NI and BAMWorkshop seem to open it ok, but BAMWorkshop II, WinBAM, and bamresize (obviously) don't.  DLTCEP throws the error message "Animation loaded with errors"

 

I have seen two different strategies used to load (and un-RLE) frame data from a BAM.  The first is to jump to OffsetToFrameData and start reading bytes.  If the frame data is RLEd, it is un-RLEd as bytes are being read until Width*Height number of bytes is reached.  The second is to read a block of data from OffsetToFrameData of the current frame to OffsetToFrameData of the next numerically higher frame data offset, then un-RLE the whole thing.  The error you have reported would make since if NI uses something analogous to the 1st method while bamresize uses something similar to the 2nd AND there are unused bytes between the blocks of frame data.  I haven't dusted off the bamresize source code to verify this yet, tho.

 

After poking CDMF4G12.BAM for a few minutes, the above scenario seems to fit.  In fact, my work-in-progress, internal-use-only BAM analyzer reports:

 

W: SizeOfFrameData>BytesReadFrameData (93184>83384)

I'll dig up bamresize off my external HD and take a look (and maybe put it on github while I'm at it...)  How urgently do you need a fix?

It's not urgent. I have already worked around the issue by decoding and re-encoding the affected files with NI's BAM Converter. Only the two mentioned files (out of over 1000) were making trouble.
 

[Sam.]

Interesting.  NI and BAMWorkshop seem to open it ok, but BAMWorkshop II, WinBAM, and bamresize (obviously) don't.  DLTCEP throws the error message "Animation loaded with errors"

 

I have seen two different strategies used to load (and un-RLE) frame data from a BAM.  The first is to jump to OffsetToFrameData and start reading bytes.  If the frame data is RLEd, it is un-RLEd as bytes are being read until Width*Height number of bytes is reached.  The second is to read a block of data from OffsetToFrameData of the current frame to OffsetToFrameData of the next numerically higher frame data offset, then un-RLE the whole thing.  The error you have reported would make since if NI uses something analogous to the 1st method while bamresize uses something similar to the 2nd AND there are unused bytes between the blocks of frame data.  I haven't dusted off the bamresize source code to verify this yet, tho.

 

After poking CDMF4G12.BAM for a few minutes, the above scenario seems to fit.  In fact, my work-in-progress, internal-use-only BAM analyzer reports:

 

W: SizeOfFrameData>BytesReadFrameData (93184>83384)

I'll dig up bamresize off my external HD and take a look (and maybe put it on github while I'm at it...)  How urgently do you need a fix?

It's not urgent. I have already worked around the issue by decoding and re-encoding the affected files with NI's BAM Converter. Only the two mentioned files (out of over 1000) were making trouble.

Actually, bamresize uses a form of the first method I described, but when the last byte of RLE'd data was expanded, there ended up being more bytes of data than width*height like there should have been.  @Argent77, I think I've come up with an effective fix, but I had to recreate my old compile environment on my new computer.  If you don't mind, I would really appreciate if you could put the new version through the ringer for me to make sure nothing got screwed up:

 

Edit: Removed attachment.  See 1st post for links to latest version

Edited by Sam., 07 December 2016 - 06:22 PM.

[Argent77]

The new version works great so far. I have processed all 17000+ BAM (V1) files from BG2EE without errors or graphics corruption.

[Sam.]

The new version works great so far. I have processed all 17000+ BAM (V1) files from BG2EE without errors or graphics corruption.

Awesome, thanks!
 
BAM Resizer is now available on GitHub!  I have updated the 1^st post and SHS download accordingly.
 

---

v2.9 (06 December 2016)

• Improved handling of corrupt RLE'd frame data.

 

[Salk]

I'm sure I am doing something wrong but each time I run the .exe, I get an error message even if everything went fine.

 

The message is:

 

File "<string>", line 1

sys.path.append('directory for BAMresize')

 

SyntaxError: invalid syntax

Processing 'nameoffile' ...

Elapsed time: 0.0 seconds

[Sam.]

I'm sure I am doing something wrong but each time I run the .exe, I get an error message even if everything went fine.

 

The message is:

 

File "<string>", line 1

sys.path.append('directory for BAMresize')

 

SyntaxError: invalid syntax

Processing 'nameoffile' ...

Elapsed time: 0.0 seconds

I've never seen that before.  What syntax, exactly, are you using to run it?  Does it still give this message if you run it as an administrator?

[Salk]

It literally shows that message no matter what I type.

 

I have attached a screenshot of my command prompt (W10) run as Administrator.

 

Attached Images

• 

[Sam.]

It literally shows that message no matter what I type.

 

I have attached a screenshot of my command prompt (W10) run as Administrator.

It seems python doesn't like the apostrophe in "Baldur's Gate 2" in your filepath.  Remove that and you won't get the syntax error.

[Salk]

Oh that was it.

 

Curious how it did work anyway though...

 

Thanks, Sam. 

Edited by Salk, 07 May 2021 - 10:12 AM.