Formatted your Sony card? Your XAVC video may still be on it.
Sony cameras don't lay video down on a card the way recovery software expects to find it. That's why you ran three different programs and got back a folder of files that won't open. We built this one around the way Sony actually writes. We're giving it away.
Reads your card image. Never writes to it. Never asks for admin rights.
Decode checking by FFmpeg (LGPL v2.1+) · XAVC S / XAVC HS · H.264 and HEVC
Built and given away by iCube Development (Calgary) Ltd.
Everything says "recovered." Nothing plays.
You pulled the card out of an FX3, an A7S III, a ZV-E1, an A7 IV. Maybe you formatted it. Maybe the camera did. Maybe it just came back as RAW one morning for no reason at all. So you ran the recovery software everybody recommends, it found a few hundred MP4 files, and not one of them opens.
That's not bad luck and it's not a bad card. It's a mismatch. Recovery software reads one way, Sony writes another way, and neither side is wrong.
Every recovery tool we've put on a Sony card works off one assumption, and it's a good assumption almost all of the time: a file sits in one solid run of bytes. Find the front of it, keep copying until you hit the end, done.
Sony's high bitrate video doesn't sit like that. The picture data for one clip is spread across the card in a bunch of separate pieces, with the sound, the camera's own frame data, Sony's bookkeeping and sometimes the next clip you shot mixed in between them. And the pieces aren't even stored in the order you'd watch them.
Copy straight through that and you end up with a file that's about the right size and completely useless. Which is what people keep getting.
- Files that won't open in anything
- Two good seconds, then a frozen mess of blocks
- Right picture, wrong audio, or audio that walks away from the video
- Correct runtime in the file properties, garbage in the frames
- Four clips welded into one giant file
- One .MP4 the size of the whole card
If you've been through this already, you can skip the reading and just grab the download. It either works on your card or it doesn't, and it costs you nothing to find out.
How Sony writes to the card
No computer science required. Here's the whole thing.
A video file is a load and a packing list
The load is the actual picture and sound. That's most of the file. The packing list is a table that says how big every single frame is, which frames got stacked together, how long each one runs, and where each stack sits.
Lose the packing list and the load is just a pile of stuff. A player has no idea where one frame quits and the next one starts. That list is the whole difference between a video and a heap of bytes.
A camera can't write the list first. When you hit record it has no clue how long you're going to hold the button. So the list gets written at the end, when you stop.
So Sony keeps notes while it works
Sony doesn't bet the whole recording on one list written at the end. While it's rolling, the camera drops little bookkeeping blocks into the stream as it goes. Inside the file they're marked kkad. They hold counters and tables the camera fills in along the way.
So the write pattern goes back and forth. A stack of video frames. A bookkeeping block. Some audio. More video. Camera data. Another bookkeeping block. Round and round until you stop, then the real list goes down at the end.
Video goes down in stacks. On the recordings we tested against, twelve frames to a stack.
Same recording, both rows. The second one is all a recovery tool gets to see, and after a format it doesn't get the labels either.
Three things that make this a pain
The gaps aren't empty. Between two stacks of picture from the same clip you've got audio, camera data, bookkeeping, or the front end of a completely different recording. There's nothing to skip over. It's all real stuff.
The counters lie. The sequence number inside a kkad block is not the video stack number. Treat it like one and you'll build something that looks right and plays wrong.
One block can cover two stacks. Some kkad blocks grow big enough to hold two video tables, and the video they describe might sit ahead of them on the card or behind them. It's not consistent.
Then a format throws out the paperwork
Formatting an SD card doesn't wipe your footage. It writes a fresh empty filing system on top of it. New boot sectors, a table that says every cluster is free, and an empty root folder.
Everything Windows knew about your clips lived in those records. Names, sizes, which cluster each one started at, whether the file was stored in one run. All of that got replaced with blanks.
Much of the footage may still be sitting there untouched. What's gone is the paperwork that described it, and without that a card full of intact video looks like a card full of nothing.
Why Sony did it this way
This layout is on purpose, and honestly it's the right call. Sony built it for the camera, not for some guy in Calgary trying to read the card two years later. Their job is to not drop your frames. They do that job well.
Recording can't stall
Sustained 4K and high frame rate capture leans on a card hard, for minutes at a stretch. The camera writes in the pattern its buffers and the card's controller like best. A dropped frame in the middle of the vows is a real problem. A carver having a bad day in 2026 is not.
Batteries fall out
Cards get yanked mid record. Power dies. If the only packing list gets written at the very end, an interrupted take is a total write off. Dropping notes in as it goes means the camera always has a recent spot to fall back to instead of nothing at all.
Sound has to ride along with picture
A player has a small buffer. It can't go hunting across a file for the matching audio. Interleaving the streams in short alternating runs means everything the player needs right now is sitting close to everything else it needs right now.
There's a third stream in there
Sony also records live camera data next to the picture and sound. Lens info, stabilization, exposure, frame by frame. That's a third thing fighting for the same write window, and it has to get mixed in too.
It works fine in Sony's world
Sony cameras and Sony's own software read this format without blinking, because they wrote it. The list at the end sorts everything out. There was never a reason for them to also make the card layout easy for somebody else's file carver.
Nobody published any of it
None of what's on this page came out of a Sony manual. We worked it out by reading real cards, holding surviving tables up against the actual bytes, and rebuilding clips over and over until they played. That's mostly why a tool like this took a while to show up.
How data recovery software actually works
There are basically two engines under almost every recovery product you can buy, plus a third thing people pay extra for. Here's each one and exactly where it runs out of road on a Sony card.
1 · Filing system recovery
The good way. The software reads the card's directory records, same ones Windows uses, and looks for entries marked deleted that are still readable. Each entry has the name, the size, where the file starts, and whether it was stored in one run.
When those records survive, recovery is close to perfect. Right names, right sizes, right everything.
Where it dies: a format swaps the directory and the free space table for empty ones. There's nothing left to read. This engine comes back with nothing, or worse, tells you the card is blank.
2 · Signature carving
The fallback, and what everything drops down to. The software ignores the filing system completely and reads every sector looking for file headers, the byte pattern that starts a JPEG or a PDF or an MP4. When it finds one it copies forward until it hits a length it believes or the next header, and calls that a file.
This is why carving works great on photos. A JPEG off a camera is small and it's almost always in one run.
Where it dies: carving only works if the file is in one piece. Sony's video isn't. Copying forward from the header drags in audio, camera data, bookkeeping blocks and whatever clip was sitting next to it, and it picks up the picture in card order instead of playback order. It's the software version of grabbing the whole shelf because you can't find the one bolt.
3 · Video repair tools
The paid tier. You hand it a broken video plus a good clip off the same camera at the same settings, and it borrows the good clip's structure to rebuild the missing packing list.
That's a smart tool and it's the right answer for a truncated recording, like a card pulled mid write, where the load is fine and only the list never got written.
Where it dies: it assumes what you handed it is in one piece and in order, and that only the list is missing. On a formatted Sony card it's usually the other way around. The list is often still sitting right there on the card. It's the load that got cut up and shuffled.
The serious forensic suites can absolutely put fragmented files back together. They do it by knowing a format well enough to predict where the next piece ought to be, and people have spent years sharpening that on JPEG, on Office files, on filesystem patterns.
But that prediction needs a model of the format, and for Sony's on card layout there wasn't a public one. So the fragment reassembly that works beautifully everywhere else has nothing to go on here, and the suite quietly falls back to carving. Which puts you right back at a folder of files that won't open. That's not those tools being bad. It's a gap in what anybody had written down.
Somebody else hit the exact same wall, in public
In October 2025, Jeff Geerling deleted a day's footage off a Sony A6700 and then wrote up every single thing he tried to get it back. He didn't know about us and we didn't know about him. He ran into the same problems this page describes, one after another, and his write-up is a better argument than anything we could put here ourselves.
-
The split files
PhotoRec found him over a hundred video files. But it split them into plain .mp4 pieces and separate _moov.mov pieces, and no combination of the two would play. He wrote a script to try gluing every possible pairing together. Nothing worked.
That's this whole page in one paragraph. The packing list and the load came off the card as two different objects, and sticking them back together doesn't help, because the load isn't in one piece to begin with. -
The repair tool
He tried untrunc, which rebuilds a broken file's index using a known good clip from the same camera. Exactly the third category described above. It got him partway: a file that played, at the right length, with brief smooth moments and a lot of frozen frames.
Its own log said about a fifth of the bytes never matched anything. That's not the tool failing. That's the tool correctly reporting that the data it was handed wasn't in the order it expected. -
Three streams, three durations
The same log listed what it found inside one recording: an avc1 video track, a twos audio track, and an rtmd metadata track, each reporting a different duration. That's the interleave we describe up top, and that rtmd track is Sony's live camera data.
His camera's sidecar file spells out what's in it: lens control, distortion correction, gyroscope, accelerometer. Which is why we strip that track out of rebuilt files by default instead of leaving a pointer to something we didn't reconstruct. -
Image the card first
He made a byte for byte image before going further, and says plainly he should have done it sooner instead of after a few passes with recovery tools. Same advice we give in step one, from somebody who learned it the hard way on real footage.
-
What finally worked
About twelve hours in, and roughly fifteen terabytes of scratch space later, he bought a commercial recovery tool for around a hundred US dollars. Its normal deep scan still gave him unplayable files. What actually worked was a separate camera specific mode, set to Sony, buried in the product's support docs.
We're not knocking that product. Somebody there did the same homework we did and their tool earned its money. But it's the cleanest proof of the point: a general purpose carver cannot do this. It takes a model built for the way one manufacturer writes to a card.
Somebody with a home lab, a NAS, backup servers and twelve hours to burn ended up paying for it anyway. Most people don't have any of that. They have one card, one shoot, and a bad feeling. So we built the Sony model, and rather than charge for it we put it on a website with a download button. If you want to check our claims against a stranger's, his write-up is worth your time.
Source: Jeff Geerling, Recovering videos from my Sony camera that I stupidly deleted, 23 October 2025.
Not affiliated with us, hasn't endorsed anything here, and hasn't tried our tool. We just found his write-up useful and it's only fair to say where it came from.
What our tool does instead
We didn't come up with anything clever. We just quit guessing. The packing lists are usually still sitting on the card, so we use those as proof, and every piece has to match before it goes in the file.
Figure out the card's shape
Find the exFAT boot area and read the cluster size and where the data starts. Not because we trust the filing system, it's empty, but because knowing the shape of the card tells us where things could legally have been written.
Read every byte of the image
One full pass, writing down every Sony XAVC signature, every kkad bookkeeping block and every packing list still on the card, then throwing out the ones that don't parse. We cache the results against a fingerprint of the image, so the second run and every run after skips this whole step.
Match each recording to its own list
Group the signatures into recordings, then pair each one with the packing list that belongs to it. That includes working out the clock offset between the timestamps in the recording and the times in the list, because they don't always agree. Pair the wrong list to the wrong footage and everything after it is wrong too.
Fingerprint every stack, then go find it
This is the part that actually matters. That surviving list has the exact size of every frame, in order, grouped into stacks. That run of sizes plus the stack's position is specific enough that basically nothing else on the card matches it by accident. So we go looking for bytes that fit the fingerprint and read as a valid H.264 or HEVC sample stream. Both, or it's not a match. If two spots both qualify, we call it ambiguous instead of picking one and hoping.
Sort out the tail ends
The last stack of a recording is short and odd, so the fingerprint trick is weaker there. Those get handled separately, using where they sit relative to the stacks we already proved.
Rebuild it, then make sure it decodes
The camera's own packing list goes back in as the index. Not something we made up that looks close, the actual table Sony wrote. Audio comes from proven card extents where they survived, with some tighter fallback rules where they didn't. Then every rebuilt video frame gets pushed through a real H.264 decoder in memory. If it doesn't decode, it doesn't get a PASS.
Regular recovery software asks "where would the rest of this file probably be?" and starts copying. Ours asks "which bytes on this card are exactly the size of frame 4,417, and do they decode?" and only copies after it gets an answer.
"Free recovery tool" usually means something else.
Yeah, we know. So here's exactly what this is, what it touches, and what it doesn't. Check it against anything else you've downloaded this week.
| What | What that means |
|---|---|
| Read only on your source | Your image gets opened for reading and never for writing. There's no code path in the thing that can modify your source. Output goes to a folder you pick. |
| No admin rights | The manifest asks for asInvoker, the same level as whoever launched it. No UAC prompt, no elevation. A tool that only reads a file you already own has no business asking for the keys to your machine. |
| No installer | Two files. The exe and the validator DLL. Unzip them wherever, run it, delete the folder when you're done. Nothing goes in the registry, nothing starts with Windows, nothing hangs around. |
| No runtime to install | Native Windows, compiled C. No Python, no .NET, no Java, no ffmpeg.exe running off in the background. |
| It actually decodes the video | Rebuilt frames get decoded in memory by a small validator DLL built on FFmpeg's H.264 decoder. A PASS means frames really decoded, and it tells you how many. It's not a checksum and it's not a guess. |
| It shows its work | Every recovery writes a CSV: clip number, stack number, where it belonged, how big it was, where on the card we found it, which bookkeeping table we used, and the evidence line. You can second guess every call the tool made. |
| Analysis only mode | Map the whole card and write no video at all. Find out how many clips are coming back before you spend the time or the disk space. |
| It remembers the scan | The full scan gets cached against a fingerprint of the image. Running it again on the same card is nearly instant, so you can mess with one clip without rescanning 128 GB every time. |
| One clip, some clips, or all of them | Rebuild a single clip by number, the first few, or everything it could prove. |
| Honest about the metadata track | We don't rebuild Sony's live camera data track, so by default it comes out of the rebuilt index instead of getting left in as a dead pointer. There's a switch to keep it if you want it. |
| Free, actually free | No account. No email capture. No key. No watermark. No file limit. No "scan is free, recovery is $89." No trial that shows you thumbnails and then wants a credit card. |
This thing leans on FFmpeg, and we're not going to pretend otherwise.
The hardest claim any recovery tool makes is "this file is good." Most of them make it by looking at the file's shape and hoping. Ours makes it by actually decoding the video, and it can only do that because of FFmpeg.
FFmpeg is one of the most useful pieces of open source software ever written. It's quietly inside a huge chunk of the world's video playback, editing and streaming, mostly built by volunteers, mostly without anybody thanking them. When our tool says PASS, that's FFmpeg's decoder saying it, not us.
FFmpeg is not owned by, affiliated with, or endorsed by iCube Development (Calgary) Ltd. We just use it, gratefully.
This software uses libraries from the FFmpeg project under the GNU Lesser General Public License version 2.1 or later (LGPL v2.1+).
The validator is built on purpose without --enable-gpl and without --enable-nonfree, using a minimal libavcodec + libavutil H.264 build.
The download ships with the full LGPL notice, the exact FFmpeg version and build configuration we used, and where to get the corresponding FFmpeg source. We patched nothing in FFmpeg.
See README-FFMPEG-LGPL.txt inside the zip for the details.
Start to finish, with pictures
Six steps. Three of them are picking folders. If you've ever used a file dialog you already know how to run this thing.
Stop using the card and make an image of it first. Every photo you take or file you copy onto that card can land right on top of the video you want back. Pull it out of the camera, then use whatever imaging utility you trust to make a raw .dsk, .img or .dd file. A hardware write blocker is ideal. A card reader you don't write to is fine. Everything below happens against that copy, so your original never gets touched.
Open the program
Unzip and double click iCube_XAVC_Recovery.exe. Keep iCubeXAVCValidate.dll next to it, that's the piece that checks the video actually decodes.
No installer, no setup wizard, no UAC prompt.
Windows is going to warn you about an unknown publisher. We sign both files, but with our own certificate rather than one bought from a commercial authority, and Windows only trusts the commercial ones. Click More info then Run anyway. We'd rather say that plainly than have you think something's broken.
If you'd sooner check than take our word for it, the thumbprint and file hashes are published so you can confirm the file came from us and hasn't been touched. Takes about thirty seconds in PowerShell.
Everything under Actions is greyed out and it says Not analyzed. That's correct. It's waiting on you to tell it where things live.
Point it at three folders
Working folder. Scratch space. The scan cache and the log go here. Any local folder with a bit of room works. Put it on a normal drive, not on the card.
Source image. The disk image you made of the card. Click Open… and pick your .dsk, .img or .dd file. This is the only thing the program reads from, and reading is all it does to it.
Recovery folder. Where the rebuilt clips land. Give it real room. You're writing full bitrate video back out, so a card that was nearly full needs a destination with about that much free space.
Once all three boxes have something in them, Analyze lights up. If it's still grey, one of them is empty.
Hit Analyze and go get a coffee
The status flips to Analysis in progress and the bar starts moving with Image scan: 4% complete.
This reads every byte of your image once. On a 128 GB card over USB that takes a while, so now's the time to walk away. It only happens once. The scan gets cached against a fingerprint of the image, so if you run it again on the same card it skips straight past this.
Nothing is being written yet. Analysis produces no clips at all, which is why it's safe to just let it run and see what you've got.
Read the results before you commit
Here's your honest picture. 238 clips recoverable means 238 recordings where we found the packing list, matched every piece of picture against it, and proved the pieces. Not found. Proved.
The four numbers underneath are how it got there. Plain english breakdown of each one is right below this section.
Recover Sample and Recover All are both live now. Don't jump to Recover All yet.
Recover one clip and actually watch it
Click Recover Sample. It rebuilds a single clip so you can check the result before spending an hour on the rest. The bottom line tracks it: Writing file 1 of 1 | clip 1 | video chunk 4/54 | 6%.
When it's done, open the file in your recovery folder and watch the whole thing. Not the thumbnail. Not the first two seconds. All of it, with the sound on. That's the only test that means anything and it costs you a minute.
Plays clean? Go to step 6. Doesn't? Have a look at what to do when something's off instead of running all 238.
Turn it loose on the rest
Click Recover All. Same job, every clip. The counter now reads Writing file 1 of 238 and it works through them one at a time.
Two bars. The top one is the whole queue, the bottom one is the clip it's on right now. Neither of them is padding the truth, so if the bottom bar sits still for a bit, that's just a clip with big stacks in it.
Leave it alone and let it finish. On a full card this is a good overnight job.
Drag the window wider if you want to watch it work
Pull the right edge out and an Activity pane appears. That's the full running log. The kkad scan, the chunk resolution pass, the rebuild, and for each clip the frame rate, the video and audio durations and the A/V offset. Newest lines at the top.
You don't need any of this to use the tool. It's there for technicians who want to see the reasoning, and for the times somebody emails us asking why a card came back short. If that's you, this pane is the useful thing to screenshot.
What those numbers actually mean
Most recovery software gives you a file count and a spinning circle. We'd rather show the working. Here's how to read it.
| 238 clips recoverable | Recordings we can rebuild and prove. This is the number that matters. It isn't "files found," it's files we matched to their own packing list and verified piece by piece. |
| Video chunks mapped: 12508 / 12517 | Stacks of picture we found and proved, out of how many the packing lists say should exist. A small gap is normal. Those are the short tail end stacks at the end of each recording, and the next line down is where they get dealt with. |
| Ambiguous mappings: 0 | Stacks where two different spots on the card both fit the fingerprint. Zero is what you want and what you'll usually get. If it's above zero we're telling you we couldn't pick with certainty, instead of picking one and hoping you don't notice. |
| Final chunks recovered: 9 | The tail ends. The last stack of a recording is short and odd shaped so the fingerprint trick is weaker there. Those get sorted out separately using the stacks either side of them. |
| XAVC + moov metadata pairs: 238 | Recordings we matched to their own packing list. If this is well below the number of clips you know were on the card, the lists themselves got overwritten, and that's a harder problem than scattered picture. |
| Image scan: 4% complete | The one full read of your image. Slowest step, happens once, then it's cached. |
| Writing file 1 of 238 | clip 1 | video chunk 4/54 | 6% | Which file in the queue, which recording, which stack inside that recording, and how far into it. If it holds on one number for a while, that clip has big stacks in it. Nothing's wrong. |
| No file is being written | Idle. Nothing is happening to anything. That's what it says before you start and after it's finished. |
Something's not right
The short list of what actually comes up, and what to do about each one.
The Analyze button is greyed out
All three boxes need something in them. Working folder, Source image, Recovery folder. Fill the empty one and it lights up.
It says 0 clips recoverable
Three usual reasons. The image isn't from a Sony writing XAVC MP4. The card got reused enough that the packing lists themselves are gone. Or you imaged a partition instead of the whole card, so the tool never saw the front of it. Re-image the whole physical device and try again before you give up on it.
You formatted in camera and got nothing at all
Worth knowing: some Sony bodies do more than a quick format. There are credible reports that the in-camera format issues a real erase to the card rather than just writing a fresh empty filing system, and when that happens the data is genuinely gone and no software on earth brings it back. Ours included.
Not every format behaves that way, and plenty of formatted cards recover fine, so it's still worth finding out which one you got. Run the analysis pass. It writes nothing and it'll tell you in one go.
Fewer clips than you know were on there
Check the XAVC + moov metadata pairs number. If that's low too, the packing lists got written over by later recordings and those clips are genuinely gone. Nothing brings back data that isn't there anymore, and anyone telling you different is selling something.
Ambiguous mappings isn't zero
Two places on the card both matched. We flag it rather than guess. The clips involved may still write out fine, so run Recover Sample and watch one. If it's clean, carry on.
The sample clip won't play
Try VLC first. The built in Windows player is fussy about odd MP4s and will refuse things VLC opens without complaint. If VLC won't touch it either, send us the Activity pane and your analysis numbers at info@icubedev.com. We're genuinely curious about the ones that fail.
Picture is right, audio is off
Audio comes from the card's own extents where they survived, with tighter fallback rules where they didn't. On a heavily reused card that fallback occasionally lands wrong. The picture is still good. Let us know and include the clip number.
It ran out of disk space partway
You're writing full bitrate video back out, so a nearly full 128 GB card needs close to 128 GB somewhere to land. Point the Recovery folder at a bigger drive and run it again. Nothing got hurt, and the cached scan means the second run goes straight to writing.
It's taking forever
The first scan reads every byte of the image once, so it moves at whatever speed your drive hands it over. An image sitting on a USB 2.0 enclosure is going to be slow no matter how good the code is. Copy the image to a local SSD first and everything speeds up.
Still stuck
Email info@icubedev.com or call (888) 728-CUBE. It's a free tool so we can't promise a turnaround, but we'd rather hear about a card it fails on than not hear about it.
iCube Development (Calgary) Ltd.
We're an IT shop in Calgary, Alberta. We do managed IT, industrial and connected device work, and data recovery. The recovery side is where this came from.
This site isn't our company site. We put sonyvideorecovery.com up on its own so the tool would be easy to find and easy to link to, without anybody having to wade through a services page to get at it. There's nothing for sale here and there's no upsell waiting at the end. Our actual shop lives over at icubedev.com if you ever need us for the other stuff.
Recovery here isn't a product line we bolted onto a website. It's the awkward one off stuff that shows up after something has already gone sideways. A controller that quit talking. A volume that mounted as RAW. An array that lost two drives instead of one. A card somebody formatted in the wrong camera an hour after the only take that mattered.
The Sony thing walked in as exactly that kind of job. We tried the mainstream recovery tools we could get our hands on, and every one of them handed back files that wouldn't play. So we started taking the format apart. Held the surviving tables up against the actual bytes on the card, built clips, watched them fail, changed something, built them again. That went on longer than we'd like to admit. Eventually they played.
Nobody here is a genius. We were just too stubborn to hand the card back. Matthew Kinderwater, our Director of IT, did most of the digging. He's been doing this kind of work for a bit over twenty years and still gets grumpy about hex editors.
Because charging for it felt wrong.
Once you've figured out how the pieces go back together, keeping it locked up means a wedding shooter, a doc crew, a student with one card and one shoot, or somebody with a recording of a person who isn't around anymore all pay a few hundred to a few thousand bucks for something a laptop can now do on its own in twenty minutes.
We already have a business. We don't need to be the toll booth on this particular bridge.
So take it. Use it on client work, put it on a tech's USB stick, hand it to whoever needs it. There's nothing to buy and nobody to ask. If it saves your footage, mention where you got it. That's the whole ask.
iCube Development (Calgary) Ltd.
Calgary, Alberta, Canada
info@icubedev.com
(888) 728-CUBE (2823)
icubedev.com
A few honest words about the recovery business
This isn't here to run anybody down. There are great labs and great engineers in this field and some of the recoveries they pull off are genuinely impressive. We've sent work to them. But it's an industry people only meet on the worst day of their month, and that shapes it. Worth knowing before you spend money.
Most jobs never need the cleanroom
The picture everybody has of data recovery is a clean room, a drive in pieces, somebody swapping heads under a microscope. That work is real, it's hard, and it costs what it costs. The equipment alone is not cheap.
But it's not most of the work. Most of what comes through the door is logical. A deleted folder, a formatted card, a partition table that lost its mind. The media is perfectly healthy and nothing needs to be opened up. Pricing doesn't always reflect that.
Pricing is hard to compare on purpose
Evaluation fees that may or may not come off the bill. "No data, no fee" that still charges for the attempt. Per gigabyte rates on media where size has nothing to do with difficulty. Quotes that firm up only after your card is already in somebody else's building.
None of that is necessarily dishonest. Outcomes really are hard to predict and a shop genuinely can't always know the number up front. But get it in writing, ask what triggers it, and ask what happens to your media if you say no thanks.
The software market is an SEO market
Search for recovery software and you'll find dozens of products with confident names, glossy screenshots and review sites that somehow all rank them in the same order. In our own testing, several of them behaved identically on the same card image, right down to producing the same broken output, which suggests a shared carving engine under different paint.
That's not a scam. Carving is a legitimate technique and those products do recover files. It does mean that trying six of them can amount to trying the same thing six times, which matches what we saw and what people describe on Sony footage.
"Free scan, paid recovery" is rough on video
The standard model is that scanning is free and you pay to write the files out. Reasonable enough in general. For video it has a specific problem. The preview you get before paying is usually a thumbnail, and a thumbnail only proves that one frame somewhere near the front decoded.
A Sony clip carved straight through will very often make a perfectly nice thumbnail and then come apart two seconds in. You can pay in good faith on evidence that's misleading. Not because anybody meant it that way, just because the preview can't test the thing that matters.
Play a real recovered file all the way through before money changes hands. Any tool or shop that's confident in its output should be fine with that.
Do this first, no matter what you use
- Stop writing to it. Take the card out.
- Don't let the camera "repair" or re-initialize it.
- Image the card and work on the copy. Always.
- Use a write blocker if you've got one.
- Keep the original image file untouched as your master.
- Try the free and read only options before you pay anybody.
And when you should absolutely call a lab
Physical damage. A drive that clicks or buzzes or won't spin up. Fire, water, crush. An array with more than one dead member. Encrypted volumes with no keys. Anything that might turn into evidence and needs a paper trail. In those cases software is the wrong tool and a good lab is worth every dollar. Call one early, before somebody's well meaning attempt makes the job harder and the bill bigger.
iCube Sony XAVC MP4 Recovery 1.0.52
Windows x64. Portable. Read only. No admin rights. Free, no strings.
iCube_XAVC_Recovery.exe + iCubeXAVCValidate.dll · version 1.0.52 · Windows 10 / 11 x64
Includes the FFmpeg LGPL notice and build details.
Check what you downloaded
Both files are signed, but with our own certificate, not one bought from a commercial certificate authority. We'd rather tell you what that does and doesn't get you than let you find out from a scary dialog.
Windows will still warn you. It doesn't trust our certificate out of the box, because trust in Windows comes from a handful of commercial authorities and we're not one of them. So you'll still see an unknown publisher notice, and PowerShell will report the signature status as not trusted. That's expected and it isn't a sign that something's wrong with the file.
What the signature does give you: if the thumbprint on the file matches the one published here, that file came from us and nobody has altered a byte of it since we built it. That's a real check. It just needs you to do the comparing, because Windows won't do it for you.
- Subject
- iCube Development (Calgary) Ltd., Calgary, Alberta, CA
- Thumbprint
- B4E8E509555A9A018E36D0F2F9B3F7583244A7D6
- SHA-256
- 27EB7E499E75B889DFAE1ED934C94481934E0E6F9D2D1027C9FD253C1D86C754
- Serial
- 1C65C2BAA2968EA645FB8FFDEC87B4EF
- Valid
- 28 Aug 2026 to 28 Aug 2031
The public certificate is here if you want it: iCube-CodeSigning.cer. You do not need to install it to run the program, and we're not going to suggest you add it to your trust store.
Both should print the thumbprint above. Ignore the Status field saying the chain isn't trusted, that's just Windows telling you we didn't buy a certificate.
And the file hashes, in case you'd rather skip certificates entirely:
- SHA-256
- d42ef5d2613cc83cf3ac5b1e209c8a63b4f1609790ea59172fab3f6029f16be5
- SHA-1
- 3894a48e22a17823ed128fe5af3af4c243b99ba2
- CRC-32
- c61633a3
SHA-512
- SHA-512
- c178df85fbfae26191be1d7b8764416add66b955d45f8e4a779d2a726b997a8f722a1abb5ab3d358be9bed51325583d0e4894e66c899bac7bf20d6c39292e922
- SHA-256
- ea5530551e2245b807146a8d1b047ecf26b120634980b94ae358842356242861
- SHA-1
- 6d847f2aba71a035c163f2685fef86bf405dddc4
- CRC-32
- 4f2b3222
SHA-512
- SHA-512
- b94e01066f33a15cba75535d1ee05471e96bfffec014319e4ea15f4c0d93a8e074f00ef8b40bc3d96a41962fdefeb609e3d5b57bb1ff32fe0ae5042a9b06b7db
Run these in the folder you unzipped to. If a thumbprint or a hash doesn't match what's on this page, don't run the file, and tell us at info@icubedev.com. We'll want to know where you got it.
Buy our team a coffee
The tool is free and it stays free. There's no version of this page where the coffee button unlocks something. But if it got your footage back and you feel like saying thanks, we went through a lot of bad coffee and a fair number of late nights figuring this out. The good stuff would be a nice change.
Goes to mkinderwater@icubedev.com · CAD · handled by PayPal · it's a thank you, not a purchase, and it doesn't unlock anything.
Stuff people ask
Is this really free, or free until I hit recover?
Really free. No paid tier, no key, no file limit, no watermark, no account. The About box in the program puts it plainer than we would: this is a free program, and if you paid for it, get your money back.
Which cameras does it work with?
Sony XAVC MP4 recordings, including XAVC S and XAVC HS layouts, H.264 or HEVC. In practice that covers a lot of Sony mirrorless and Cinema Line bodies. ZV-E1, FX3, FX30, A7S III, A7 IV, A1 and their relatives. Not because we special cased each model, but because they share the same recording layout.
Pro MXF wrapped XAVC is a different container and this tool doesn't go there.
Why does it want a disk image instead of the card?
Safety, mostly. Working from an image means the tool physically cannot touch your original no matter what goes wrong, and you can rerun the analysis as many times as you want without the card being in the machine. Imaging first is also just good practice, so it doesn't really cost you anything you shouldn't be doing anyway.
Does it need admin rights?
No. The manifest asks for asInvoker, so it runs as whoever launched it. You won't get a UAC prompt. A tool that only reads a file you already own shouldn't be asking for the keys to your machine, and we didn't want to be one of those.
Can it hurt my card?
It never opens your source for writing. It reads the image you point it at and writes rebuilt clips into a separate folder you choose. And if you follow the recommended workflow, image the card then work on the image, there's a second layer between the tool and your original anyway.
How do I know the recovered files are actually good?
Two ways. The tool decodes the rebuilt frames through FFmpeg's H.264 decoder before it calls a clip PASS, and it tells you how many frames decoded. And it writes a CSV showing where every single piece came from, so you can check its work instead of taking its word.
Then play the file. All the way through. Always play the file.
What if some clips don't come back?
Then they don't, and we'd rather tell you that than pretend. If a chunk of data got genuinely overwritten by later recordings, no software on earth can bring it back. The tool reports missing or ambiguous pieces instead of filling them with something that looks plausible and calling it a win. Run the analysis pass first and you'll know where you stand before you spend the time.
Why couldn't the software I already tried do this?
Because the common approach assumes files sit in one solid run, and Sony's high bitrate video doesn't. Copying forward from the file header drags in audio, camera data, bookkeeping blocks and neighbouring clips, and it collects the picture in the order the camera wrote it instead of the order it plays. You get the right file size and nothing else. That's a gap in what anybody had documented, not those products being junk.
Why is iCube Development giving this away instead of selling it?
We're an IT and recovery shop in Calgary with an existing business. This came out of one real job where nothing on the market worked. Once we'd figured out how the pieces go back together, charging for it would have meant videographers, students, doc crews and families paying hundreds or thousands for something a laptop now does on its own in minutes. Giving it away seemed like the better use of the work.
Isn't there already a paid tool that does this?
There's at least one, yes, and by the accounts we've read its camera specific mode works. Somebody over there did the same homework. We're not going to pretend otherwise just because we're giving ours away.
The difference is what you get for nothing. Ours is free, it never writes to your source, it shows you the analysis before you commit, and it writes a report saying where every single piece came from so you can check its work. If a paid tool suits you better, use it. We'd just rather nobody had to spend a hundred bucks to find out whether their card is recoverable.
Can I use it commercially, or in my own shop?
Yes. Use it on client work, keep it on a tech's USB stick, make it part of your standard Sony workflow. Nothing to buy, nobody to ask. Just keep the FFmpeg LGPL notice with the files. A word to your clients about where it came from is appreciated but not required.
What's FFmpeg doing in here?
Providing the decoder that checks our work. The validator statically links a minimal libavcodec and libavutil H.264 build under LGPL v2.1 or later, configured without --enable-gpl and without --enable-nonfree. FFmpeg isn't owned by or affiliated with us. The LGPL notice, the exact version and build configuration, and where to get the corresponding FFmpeg source all ship with the download.
My card is physically damaged, not formatted. Will this help?
No, and please don't spend your evening on software for that. If the card isn't reading reliably, if it's cracked or wet, if a drive is clicking or won't spin, that's physical recovery and it needs a lab with the right gear. Software attempts on failing media can make a professional job harder and more expensive. Call somebody early.