@NightShadow... That is correct, if that is the way you are going, but if you or others go the other way, Windows dates to Meta changes the results are different. Below are 2 different uses Meta2CRT and CRT2META. Notice the One direction is catastrophic for 2 files that are playable and have a thumbnail (Meaning the decoder also liked them).
Going MetaData to Windows Created/modified should be no problem but it is ALWAYS a good procedure to keep originals until editing is done and verified. Many have written in here and asked how to fix corrupted files after they no longer have the source files and the answer is always the same. I will post the new link as soon as my faster internet is up again.
+ Reply to Thread
Results 31 to 49 of 49
Last edited by Budman1; 12th Dec 2016 at 20:50.
The new version
Last edited by Budman1; 8th Feb 2019 at 22:48. Reason: changed link
@NightShadow, That looks like the right selection but bear in mind that after the file is changed the date and time in the lower box will not change until you click the file again.
Update... Just checked and sure enough I was asleep again when I coded it. Think this is fixed now. I changed the link and it should work now.
New Version https://files.secureserver.net/0sqAfho5vHt8P9
Last edited by Budman1; 8th Oct 2019 at 22:23. Reason: New version being redone
@Nightshadow... looks like we have a mismatch in out versions. Notice the double backslashes? Your computer is actually working in the F:\ directory. I do add the backslash to the path but because my visual studio does not include it when finding the root filename. I added a couple popups to a version to find out where your version picks up the slash if you would care to try. I'll upload and send link in PM. If I may ask, what version of Windows do you run and what .NET version?
In the mean time I'll try to find a way around this without adding the slash.
Thanks for your response and help fixing for others who may have this problem.
@Nightshadow Okay I gave Microsoft a chance and changed the coding to allow the version of software to add the backslash if it needs it or not if it doesn't. It works correctly on mine so please let me know. I also cleaned up the code so if you choose a second folder for the 'TO' files but still check the change original, the program will change the original anyway.
All my tests worked okay against an internal hard drive but if you use a USB or 'slower' drive, there is a timing in there between DOS and Windows and I think I allowed for that.
I'm going to send you a PM with an email we can use for this issue so we don't make this thread uglier.
I also changed the link above to the new version 184.108.40.206 which is now shown in Title bar
Last edited by Budman1; 27th Dec 2016 at 15:08. Reason: Version wrong
I am still getting 0kb files and the same error I posted yesterday with the new version.
I am not sure this app can do this particular date change I am wanting...
Windows file properties dates are all 2001 for this file, Created, Modified Accessed. But see the jpeg here, on the left, you see the windows file properties DETAILS panel... over ehre the date of 2013 is under a section called Media. This date is also seen by Adobe Bridge (on the right) and by Google Photos (I believe). So I do not know if this 2013 "Media" date is the same as the encode date? If so, this will help a lot if I can get it working.
Were my settings on your app correct to make this date change?
I may have found out something.
TWO of a batch of 10 DID actually convert.
These two files are the only two in this batch which do not have Language English in the Codec info, see jpeg. All the others say "Language : English" and they come out as 0kb files.
ALSO, this shows how the files are 0kb, but interestingly too, that the Windows basic dates all changed to today's date, which is definitely not what I intended
I believe the problem may be due to the script written to encode the encoded date. First of all, if the video had other than 2 tracks, audio and video, the script has to have additional parameters. These would have to be gotten from the file. This is why I asked for the MediaInfo of one that fails or a small one I can download to test.
Also, FFmpeg seems to be particular when it comes to this function in that '-c copy' does not work the same as ' -acodec copy -vcodec copy' and these work differently than '-c copy - map 0' or '-acodec copy -vcodec copy -map 0'. It all depends if the MP4 has Header, menu, chapters, object desciption, etc. These all have to be handled differently. I am working on ones that I have with subtitles and object description to come up with a generic script that will work on these. Otherwise I will need to interrogate the individual mp4 files for what it contains.
Flac files already fail due to the different methods and format that contain the encoded information.
If you have a small sample that fails and/or the MedaiInfo data of this file, please post it and I will try to alter the program.
Here attached is a small file which fails.
I thought I should tell you that I found a file which had Language English which did re-encode properly.
Today I am going on holiday for a week, and will have very limited internet access, but would love to know if you manage to figure out what is happening here. None of these files have chapters or built in subtitles.
@fredphoesh, Thats a strange little file for ffmpeg at least. The atoms have some strange ones especially UUID. Looks like it was once on an IOS system or tagged by itunes new format which ffmpeg will not handle yet.
Atom ftyp @ 0 of size: 32, ends @ 32
Atom wide @ 32 of size: 8, ends @ 40
Atom mdat @ 40 of size: 1550904, ends @ 1550944
Atom moov @ 1550944 of size: 438478, ends @ 1989422
Atom mvhd @ 1550952 of size: 108, ends @ 1551060
Atom trak @ 1551060 of size: 6131, ends @ 1557191
Atom tkhd @ 1551068 of size: 92, ends @ 1551160
Atom load @ 1551160 of size: 24, ends @ 1551184
Atom tref @ 1551184 of size: 20, ends @ 1551204
Atom sync @ 1551192 of size: 12, ends @ 1551204
Atom mdia @ 1551204 of size: 5987, ends @ 1557191
Atom mdhd @ 1551212 of size: 32, ends @ 1551244
Atom hdlr @ 1551244 of size: 44, ends @ 1551288
Atom minf @ 1551288 of size: 5903, ends @ 1557191
Atom vmhd @ 1551296 of size: 20, ends @ 1551316
Atom hdlr @ 1551316 of size: 32, ends @ 1551348
Atom dinf @ 1551348 of size: 36, ends @ 1551384
Atom dref @ 1551356 of size: 28, ends @ 1551384
Atom stbl @ 1551384 of size: 5807, ends @ 1557191
Atom stsd @ 1551392 of size: 211, ends @ 1551603
Atom avc1 @ 1551408 of size: 195, ends @ 1551603
Atom avcC @ 1551494 of size: 51, ends @ 1551545
Atom uuid=6b6840f2-5f24-4fc5-ba39-a51bcf0323f3 @ 15
51545 of size: 28, ends @ 1551573
Atom colr @ 1551573 of size: 18, ends @ 1551591
Atom stts @ 1551603 of size: 24, ends @ 1551627
Atom stss @ 1551627 of size: 108, ends @ 1551735
Atom stsc @ 1551735 of size: 3256, ends @ 1554991
Atom stsz @ 1554991 of size: 1104, ends @ 1556095
Atom stco @ 1556095 of size: 1096, ends @ 1557191
Atom trak @ 1557191 of size: 6547, ends @ 1563738
Atom tkhd @ 1557199 of size: 92, ends @ 1557291
Atom edts @ 1557291 of size: 48, ends @ 1557339
Atom elst @ 1557299 of size: 40, ends @ 1557339
Atom tref @ 1557339 of size: 20, ends @ 1557359
Atom sync @ 1557347 of size: 12, ends @ 1557359
Atom mdia @ 1557359 of size: 6379, ends @ 1563738
Atom mdhd @ 1557367 of size: 32, ends @ 1557399
Atom hdlr @ 1557399 of size: 44, ends @ 1557443
Atom minf @ 1557443 of size: 6295, ends @ 1563738
Atom smhd @ 1557451 of size: 16, ends @ 1557467
Atom hdlr @ 1557467 of size: 32, ends @ 1557499
Atom dinf @ 1557499 of size: 36, ends @ 1557535
Atom dref @ 1557507 of size: 28, ends @ 1557535
Atom stbl @ 1557535 of size: 6203, ends @ 1563738
Atom stsd @ 1557543 of size: 103, ends @ 1557646
Atom mp4a @ 1557559 of size: 87, ends @ 1557646
Atom esds @ 1557595 of size: 51, ends @ 1557646
Atom stts @ 1557646 of size: 32, ends @ 1557678
Atom stsc @ 1557678 of size: 3256, ends @ 1560934
Atom stsz @ 1560934 of size: 1708, ends @ 1562642
Atom stco @ 1562642 of size: 1096, ends @ 1563738
Atom udta @ 1563738 of size: 425684, ends @ 1989422
Atom meta @ 1563746 of size: 425676, ends @ 1989422
Atom hdlr @ 1563758 of size: 32, ends @ 1563790
Atom ilst @ 1563790 of size: 425632, ends @ 1989422
Atom cday @ 1563798 of size: 34, ends @ 1563832
Atom data @ 1563806 of size: 26, ends @ 1563832
Atom cnam @ 1563832 of size: 34, ends @ 1563866
Atom data @ 1563840 of size: 26, ends @ 1563866
Atom desc @ 1563866 of size: 24, ends @ 1563890
Atom data @ 1563874 of size: 16, ends @ 1563890
Atom covr @ 1563890 of size: 425532, ends @ 1989422
Atom data @ 1563898 of size: 425524, ends @ 1989422
Atom free @ 1989422 of size: 1024, ends @ 1990446
~ denotes an unknown atom
Total size: 1990446 bytes; 63 atoms total. AtomicParsley version: 0.9.0 (utf16)
Media data: 1550904 bytes; 439542 bytes all other atoms (22.083% atom overhead).
Total free atom space: 1024 bytes; 0.051% waste.
UPDATE: New Version https://files.secureserver.net/0sqAfho5vHt8P9
Last edited by Budman1; 8th Oct 2019 at 22:22. Reason: update version posted
Hello Mr. @Budman1,
I was searching for a program that does exactly what the program you created does and I've tried your program and it works great, with only one issue and that is some times I get a error message saying that media info has not returned information in 0.005s and that the file will be skipped. After I hit okay it actually creates the new files with the changed attributes but If I try to do more than one file it doesn't work. I'm using windows 10, not sure if you have the time to help me but I would really appreciate it.
@bulls23ant, There is a built in 5 second delay for MediaInfo to get the information from your file. This is necessary because, ever since around Windows XP, A windows program will turn Dos loose and continue on. Since I use the CLI MediaInfo and then check the results, if I didn't pause, the results would never be available in time. If you are using a USB drive or a large MOV file and other reasons, the MediaInfo may not be available in 5 seconds.
It may show up before you click ok but normally it is set to skip this file and go to the next. I'm interested in if it actually does complete and in what direction, Created2Encoded or Encoded2Created?
If I try to do more than one file it doesn't work
@Budman1 the direction I'm using is Encoded2Created. If I put 4 files on the batch it will go through all 4 files showing the mediainfo 5 sec time out message for each of them. I press okay in all of the messages and at the end only 1 new file is generated with the fixed created date (the first file). I also discovered that the timeout happens with older videos taken it 2009 with an older iphone, new videos taken last December get processed correctly with no timeout message.
@bulls23ant can you post the MediaInfo for one of those 4 videos and I assume they actually HAVE an Encoded date in MediaInfo correct? There is a chance that the 'atoms' that store this data are in different areas than the later files and it is taking longer to find in a long file. This is why a mediainfo printout would help. You might also run 'AtomicParsley.exe C:\path\video.mov -T' and check both files against each other. You may find a big difference in the layout of the atoms. You are looking for MVHD, TKHD and MDHD locations,
@Nemesis84... Thanks. It was a team effort. Many people helped with suggestions, errors reported and patience. The latest version can be found as a tool on this site under Date Time Changer. It can also be downloaded from my online storage at Change_Date_Time_1_17_06_08 https://files.secureserver.net/0sqAfho5vHt8P9