When trying to change the metadata on the NYT1 2014 MU69 image taken by New Horizons image that I downloaded from a blog post, I get this error:
An unexpected error is keeping you from appying properties to the file. If you continue to receive this error, you can use the error code to search for help with this problem.
Error 0x80070057: The parameter is incorrect.
Screenshot:
Some observations:
- The path of the file location is nowhere near 256 characters long
- The file name is not any of the Windows reserved names
- The file is not read-only, and I have full read/write permissions for the file.
- Even if I re-download the image or rename the image, the error still reliably appears every time.
- I can still edit the metadata on other JPEG files in the same folder just fine, so I don't think this is related to system or hard drive corruption.
- If I push "Skip", the action completes, but then no metadata is changed.
Possibly related threads that I already looked at:
- Error 0x80070057 when editing JPG metadata through explorer
- Error 0x80070057 when adding photo tags in Pictures folder
- Error 0x80070057 when attempting to change image metadata shown at the bottom of explorer
- Error 0x80070057 when copying images from iPhone 5s to Windows 8.1
- Error 0x80070057 when deleting Autorun.inf.mal folder
2 Answers
I don't know the root cause of this error, but it seems to have something to do with the file itself. Using exiftool to repair corrupted EXIF seems to fix the problem. The command looks like this:
exiftool -all= -tagsfromfile @ -all:all -unsafe -icc_profile bad.jpgMore detail on what this does:
This command deletes all metadata then copies all writable tags that can be extracted from the original image to the same locations in the updated image. The "Unsafe" tag is a shortcut for unsafe EXIF tags in JPEG images which are not normally copied. JPEG images may also contain an ICC color profile which should be preserved. The "ICC_Profile" tag is also marked as unsafe, but is not part of the EXIF so it isn't covered by the "Unsafe" shortcut and must be specified separately.
Note: ExifTool will not modify the JPEG image data.
Advanced: The byte order of the newly created EXIF is set by the value of the ExifByteOrder tag. If ExifByteOrder is not set then the byte order is determined by the ordering of the MakerNotes if they are copied, otherwise big-endian ("MM") byte order is used by default. ExifByteOrder may be set to a specific value to force a particular byte order when creating new EXIF (eg. "-ExifByteOrder=II" for little-endian).
Note also that running the above command on a file named bad.jpg will preserve a copy of the original file under the filename bad.jpg_original.
I've run across the same problem with video files, where mostly the extra metadata can easily be changed, then you run into some that no matter what you try in properties, it wont work. I tried several times just now to rid the video (mp4) of the Title (not filename) by opening properties (didn't work) and then by making a copy to remove all data, that to didn't work.
What did work was I made a copy of the file and placed it on my desktop, I then opened Wondershare Video Converter Ultimate or the newer one, and in toolbox selected fix metadata. After it did it's thing I right clicked on the file and under properties - it still had the annoying title. However, I right clicked on the file - opened properties and simply erased the title and clicked okay. I rechecked and it was gone.
Don't know why but it seems this did the trick. Now I got several more files to check and rid them of the metadata someone placed there.
Know it's been a long time since this thread was opened, but hopefully it will help someone else.
Okay, I just finished 6 more videos, stripping them of the added metadata, all work fine and no longer show up the idiotic title when listed on my TV. (thanks for nothing TBox).
But this does solve my problem and should work for anyone if you have a video program that allows metadata fixing. Mine warns you to work with a copy, not the original, which makes sense.
Anyway, I was looking for a good while on how to solve my problem, appears I wasn't the only one.
