CC24 Corrupt file or unsupported InDesign version

Started by sf66, September 17, 2024, 01:25:07 PM

Previous topic - Next topic

sf66

Hi,

We are using Exiftool version 12.96 and are having problems with some InDesign CC24 files in that Exiftool is stating that they are corrupt or are an unsupported InDesign version.

We can open the files in InDesign ok and if we re-save them then Exiftool doesn't report the problem anymore, but we don't know what is causing the error initially.

I've attached the output of exiftool -s for reference.

Hope you can help.

Thanks




StarGeek

Can you supply a sample? There's nothing that can be done with simple exiftool output to see the actual interior structure of the file.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype


Phil Harvey

There looks to be some garbage at the end of this file after the last object trailer (the object trailer for the XMP block ends at 0x42ff83, and the only valid data after this would be an object header or null padding, but instead there seems to be part of the XMP data).  The dump below shows from the end of the XMP packet (which ends at 0x42ff63 and is followed by the 32-byte object trailer) to the end of the file.

I believe this is a problem with whatever software wrote this file.

  42ff50: 3c 3f 78 70 61 63 6b 65 74 20 65 6e 64 3d 22 77 [<?xpacket end="w]
  42ff60: 22 3f 3e fd ce db 70 f7 86 4b 4f a4 d3 c7 28 b3 ["?>...p..KO...(.]
  42ff70: 41 71 06 01 00 00 80 00 00 00 c0 43 ef 02 00 e7 [Aq.........C....]
  42ff80: 01 5a b1 20 20 20 20 20 20 20 20 20 20 20 3c 73 [.Z.           <s]
  42ff90: 74 46 6e 74 3a 66 6f 6e 74 46 61 63 65 3e 52 65 [tFnt:fontFace>Re]
  42ffa0: 67 75 6c 61 72 3c 2f 73 74 46 6e 74 3a 66 6f 6e [gular</stFnt:fon]
  42ffb0: 74 46 61 63 65 3e 0a 20 20 20 20 20 20 20 20 20 [tFace>.         ]
  42ffc0: 20 20 20 20 20 20 20 20 20 3c 73 74 46 6e 74 3a [         <stFnt:]
  42ffd0: 66 6f 6e 74 54 79 70 65 3e 4f 70 65 6e 54 79 70 [fontType>OpenTyp]
  42ffe0: 65 43 46 46 3c 2f 73 74 46 6e 74 3a 66 6f 6e 74 [eCFF</stFnt:font]
  42fff0: 54 79 70 65 3e 0a 20 20 20 20 20 20 20 20 20 20 [Type>.          ]

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

sf66

Ok, thanks Phil.

I believe this file and the others have been created and only edited in Adobe InDesign CC24.

Is there a way this can be corrected programatically or is the only option to open and re-save in CC24?

We also want to write metadata to these files as part of our workflow and it is happening on approximately 30% of the CC24 files we're receiving from multiple sources so is quite a problem.

Thanks



Neal Krawetz

Any idea where that trailing garbage came from?

I'm wondering: If you make an edit that causes the file to be smaller and then hit 'save', does it overwrite without truncating? Basically, are you seeing some residue left over from a previous save?

Or is this some kind of additional data that they are adding to the end of the file?

Phil Harvey

#6
I'll look into adding a patch to allow files like this to be written.  The safest thing to do would be to copy the garbage to the new file.

- Phil

Edit: I think this is likely a byproduct of the fact that INDD files are an even number of 4096-byte blocks.  There is a good chance of padding after the last record, but in the past it has always been nulls.  So just copying the garbage won't work because the file will need to be padded after any edit, so it will continuously grow for each edit unless the garbage (or maybe just any null padding added to the garbage) is dropped.  I need to think more about this.

Edit2: OK.  I've got a patch working that makes this a minor error.  With the -m option ExifTool reads up to 4095 bytes of non-null garbage from the end of the file (if there is more, then ExifTool will generate an unignorable error) plus up to 4095 null bytes, then trim any trailing nulls, and add back the garbage with null padding added to the fill the last 4096-byte block.  PITA really, but expect this update in ExifTool 12.97
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

sf66

Thanks Phil,

Much appreciated. Is there an ETA for 12.97?


Phil Harvey

...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).