Messages

It's actually something you'd want. Doesn't sound like Canon of recent.

[Offset]

I'm not aware of a tool that does this automatically so I did it manually. If anyone does know a tool that does it, however, I would also like to know.
Anyway, all the small .MLV files are not needed. The large files are the ones that contain everything.

The block that is affected is shown in MLV_dump as Offset:0x00......
So, from that offset mlv_dump showed onward, upto the next NULL@... (you can use Ctrl+F for that), til the last box.

So a block looks like:

Code Select Expand

VIDFĄé,.Ķ...........
lots and lots and lots of stuff here


And the next block after:

Code Select Expand

VIDFĄé,.Ķ...........
lots and lots and lots of stuff here


Let me break it down so it could actually be followed:
In HxD you can use "Select Block" or Ctrl+E to select the block.
When on the main screen, the location (the offset) is shown in the lower left corner.
This is what you need to enter into Ctrl+E.

• First number is from mlv_dump.
• Ctrl+F  "NULL@" and select the last empty box you see.
• Make a note of the number in the lower left corner.



• Scroll randomly way down and select a random block.
• Ctrl+F VIDF. Note the offset.
• Ctrl+F "NULL@" and select the last empty box you see. Note the offset.

Enter those last two numbers into Ctrl+E. OK.
Do Ctrl+C.
Enter the first two numbers into Ctrl+E. OK.
Do Ctrl+V.

"Save as" to a new MLV file (Do not overwrite the current one).

I once had a bunch of MLV files I couldn't open so in case it repeated itself I wrote this guide (for myself): https://www.upload.ee/files/6251711/MLV_FIXING_GUIDE_v1.11.pdf.html
It didn't happen again. I instead had a bunch of h264 files I couldn't open when another card decided to call it quits. There's a tool for that but that's off topic.

Download the nightly from march 31 !  ;-)

March 31, 2015

If the card shows as having any data on it, they're probably somewhere on it. If Windows (I am presuming you have windows) tried to repair the file system they might be in a hidden "F:\found.000" folder. (drive F: is just an example). Other than that TestDisk or PhotoRec might be the way to go if you're not uncomfortable using the command line (PhotoRec also has a GUI called qPhotoRec).

Press W to close the browser. The folder you navigated to is now set.

It does: "C - Export all files in the current directory using the current settings."
The keys and their functions are detailed here.

I did update it, but forgot about the link in this post. Sure, I'll send it to you in a PM.

If that doesn't work, you'll have to run it through MLV_dump to see what's wrong with it.

Presumably you are using MLRawViewer to export? You might try MLV Magic if the corruption occurs towards the end.

Edit: Sorry, I meant MLV Mystic.

Very interesting.

I made a (rather long) post about a similar situation.

This is how I resolved it: http://www.filedropper.com/mlvfixingguidev11_1
Could be helpful, could be not. I sure didn't find the situation amusing.

This will be a long read, however, hopefully an entertaining scribbling of idiocy and desperate quiet anger. Enjoy.

So, a couple of Sundays ago, before nerve wrecking and data restoration, I was shooting on a pond. As it's customary while shooting raw, we ran out of card space just when we didn't have time to spend. Only time to take the card and transfer about 2-3 files off the card to get a couple of takes in and then drive one of the actors where he wanted to.
Laptop open, card in, Ctrl-X and Ctrl-V. Going, going. Not. Not going. Frozen to a snail's pace at 44 bits per second. No good. Spent 3 of the 5 minutes I had for this already. Maybe the card is too full – delete the .tmp file. Going. Going. No. Stiff as a board. That's fine, happens. Unplug, redo, delete. Bing, bang, boom, out and shoot two more takes. Looking good.
Take the actor home, swing by the house to unload the MLVs over a USB3 connection before heading back for the last shots of the scene.
Plug in, card full – great, select the files and.... hold on. Select the files again. What's this? Properties. 29 GB? Out of 59GB? *alarms seeping in and out through the veins in my eyes*  Copy all that's there off the card. Open. No. No, only a couple of them work. Something's way, way, way the hell off. Can't touch the card now. Scrap all other plans. Get the gear from the woods and get to the bottom of this.
Sit down, form a plan. Raw dump of the bits using ,,HDD Raw Copy Tool" (didn't work, later on rewriting it to the card was only greeted with an access error).
Run chkdsk to repair the file system (was able to get 29 out of probably 32 files out, 90% with conversion preventing damage). Folders FOUND.000 and FOUND.001, you magnificent bastards.

Do they start? No. Convert? No. Do they have size to them? Yes. So... I could have the files or... I could have a bunch of fancy shredded paper. No clue at this point and no experience that could soothe my nerves in any direction.
Some kind of data copied, a raw copy of the entire card as a fallback, time to break out every kind of partition/card/HDD data rescue program you can get your hands on through the internet.
Nothin'. Fancy didn't work. Break out the CLI. Testdisk stumped. Photorec stumped. Fine, the card doesn't want it, I don't want it either then. Let's see about the rescued files. Maybe some hope of salvaging any kind of mood out of it... or complete and utter realization of the start of things tirelessly going wrong that week.
Where to start? Someone must have at least had something similar happen, right? Or has it? A post on the Magic Lantern forum about damaged headers, HEX values mentioned. So HEX is the key? Hex it is. Open up the file. What? No words to even find. Absolutely no experience with the structure of the MLV files, what constitutes a block even? Magic Lantern forums. Someone mentions MLV_Dump.

For the sake of sanity, let's skip the chapters of the learning process and proceed all the way to the getting things back on track day. HxD the tool of choice. Some files – headers gone. Other files – damaged frame(s) with VIDF blocks needing replacement. Metadata in some places, metadata....not...in other similar blocks.  Handicraft and test runs through MLV_Dump.exe to work my way through. A third of the previously dead files have frames with visual glitches here and there, but a tremendously larger amount of files saved in total than hoped. Brilliant. Almost everything there. Moments that won't be lost like bits on a broken disc. It's late, better finish tomorrow... *a dark cloud peaks afar* you've earned it...
Morning. Let's go. Boot. Get the external drive. Alright. It's taking a minute. It's always been slow. Taking a while, though. Replug. Yes, this is it. Should work. Taking a bit, though. Re-do. It's not doing it. The *censored* drive I just put hand*censored*fixed *censored* files on! Come on... at least enough to catch my breath. Noup, does not comply. Fine, shred the damn external case. Hook up to PC direct. No. No, it won't work. With all other projects on it that have no back ups, better not force it before making a raw dump first.

Skip the scarping together of money and purchasing a drive and a successful recovery two days later.

Got it all, let's get things on track. Get the camera, format, test. Nice. Restart. Format.... hang on. Redo. No, no... Plug in to PC, format, replug: ,,This card needs to be formatted before use"
*cue head meets desk* ...a break.  I mean, I'll take anything at this point. Just please can I not get hit by lightning on Friday at this rate?
Card? No good. Cannot hold any kind of format by any tool known to man. Tried them. As soon as you reinsert the card or cycle the camera the thing is jumbled. HEX looks like a wheel-of-disorder all over. No matter what your wrote before. Effectively dead. Only Lexar itself can help now. And they are. It'll be swapped.

What should have been a day of shooting took two weeks to sort out in total. Moral of the story? I don't know if there is one. Don't hurry perhaps. Especially when you have to. It only changes it from a chance to a probability.
I wrote a guide for my own personal use in case I should ever need to repair a MLV again. Hopefully it'll be under a thick stack of digital dust in the future.

The way I went about fixing the MLVs, written by someone who has approximate knowledge about many things... so assume nothing:

Edit: Updated the guide to a much better version.

For extra information, the file cannot be opened in Premiere either. Also, Irfanview displays an error of "Decode Error: Not a valid RAW file" when trying to view it. A dng from MLRV for example is viewable, though very very pink in Irfanview.

The result is this (Resolve 12):

Regarding wrapping: I too thought about MXF wrapped DNG sequences.

So it turns out (based on the information I have gathered) that while it is stated in the CinemaDNG Image Data format Specification, the standard that defines these parameters is still somewhere in between the draft phase and release (SMTPE 379-2 and/or SMPTE ST 2055 I believe). Which is fine, as it should still be possible to create DNG MXF's.

Through some digging I was able to get my hands on a couple of actual DNG .MXF files, provided on the Adobe CinemaDNG labs page a couple of years ago (2011/2012) before being taken down. As far as I can tell no player, NLE, encoder or decoder can actually read these kinds of files. Maybe they're of use to someone else.

Ref. (sans http://)
download.macromedia.com/pub/labs/cinemadng/cinemadng_p3_longsample_mxf_082310.zip
web.archive.org/web/20110320050921/http://labs.adobe.com/technologies/cinemadng/
download.macromedia.com/pub/labs/cinemadng/cinemadng_p1_sample_091009.zip
web.archive.org/web/20120918202214/http://labs.adobe.com/downloads/cinemadng.htm

The long sample was created with "Adobe Systems Experimental CinemaDNG MXF Writer 0.10.804.0.5"

I got the exact same error message when I was trying a beta build of Win 10. Seems to be caused by an issue with Microsoft C++ Redistributable. After I had installed a couple of adobe products and they in turn installed C++ 2005,2008, 2010, 2012 redistributables (x86 and x64), MLRawViewer started up without a hitch. I'm not sure which exact one is needed but the problem lays with them.