633 vs MAXX- Yet again

[judykarp]

Thank you Derek.  

[Jeff Wexler]

"If you abort the mirroring before it completes a segment the mirrored BWAV is lost. It’s all or nothing. The MARF recording is fine and after a reboot of the recorder it recovers without any issue, just like it was designed to do, which is amazing."

 

I had to read this twice and then continue reading to really understand what you meant by "abort the mirroring" process. If you are not using Continuous Mirror and you are in fact mirroring and you go into record, the mirror process is "aborted" but picks up right where it left off when you hit STOP.

 

"I then physically ejected the CF while still rolling."

 

Now I understand what you been by abort --- this is fine in terms of expediting your test but it should be noted that "ejecting the CF while rolling" is a rather drastic event that I can't imaginer would ever happen while working.

 

"The “Mirrored” BWAV, which never finished past 99%, was still zero kb and unplayable."

 

Once you have recovered the whole MARF recording (amazing, as you state), couldn't you just re-mirror?

Will I sell my Maxx and get a 633 just for this reason? No, but it does mean I have to consider file transfer a little more carefully especially if I’m trying to integrate my Maxx onto a project where Sound Devices recorders are being used and there is a data manager who is only familiar with one method for sound transfer.   

[studiomprd]

JW: " "ejecting the CF while rolling" is a rather drastic event that I can't imaginer would ever happen while working. "

not being aware that your batteries are dying is a rookie mistake, too...

[glenn]

That was a great post but a few things need to be clarified. The Nomad and MAXX are recording both MARF and FAT32 files at the same time.  Since you were 99% on the mirror files it was telling you that it had recorded both with no issue. When you pulled the card during the recording the MAXX backup system proved it self out as we designed it to. We make sure that the MARF files are always recovered first to the exact moment of the event that stopped the recording. The file that was being mirrored will need to be remirrored but that is usually a much faster than real time function and an automatic one at that.

 

Had you stopped the recording in the normal way both copies of the audio would be instantly ready to go.

 

From the Zaxcom perspective we will always safegard the audio in the MARF directory. We will always write the directory only twice per recorded file to minimize the possibility of a complete failure of the disk recording system due to a corrupted directory. This also eliminates the possibility of card burnout (Not a big factor these days). We will also recover all of the audio in the case of a unexpected event like loss of power or media ejection while in record. MARF is an importaint feature in any of our recorders and one that will always come through when all hell is breaking loose in the case of corrupted or accidently erased media.

 

Glenn

[Derek H]

Yes ejecting the CF while rolling is drastic and would never happen in real use but I figured it would provide a good 'torture test' to reveal how the MARF system really works and if it had any limitations. It passed with flying colors. I can only imagine it would work exactly the same way if you lost power while rolling. 

 

Sorry for the confusing terms Jeff, I need to work on my run-on sentences!

 

Batteries dying being a rookie mistake? I agree, and this is unlikely to happen with the Maxx as it's very light on power useage. A fully charged IDX NP1 will get you through most full days even powering a whole bag. Change at lunch and the possibility of losing power is pretty much eliminated.

[Jeff Wexler]

JW: " "ejecting the CF while rolling" is a rather drastic event that I can't imaginer would ever happen while working. "

not being aware that your batteries are dying is a rookie mistake, too...

Batteries dying would not cause any of the "issues" we are talking about, Senator. There are all sorts of "rookie mistakes" (like maybe dropping the machine in the toilet) but ejecting the CF card while rolling is probably the absolute least likely occurrence. As I said, ejecting theCF card for purposes of this test (and thank you, Derek, for providing us with this test) is probably the least likely ever.

[Christian Spaeth]

The problem seems to be that you hand in your card at the end of every shoot but then nothing happens with the data until very much later when the final edit is about to get done. So there seems to be no real pressure in handing in files every day, does there? For me, there's two kinds of jobs:

1 - I hand in the data every day because they instantly want to edit it. Then you can be sure they will have and save the data, so no second card should be necessary.

2 - doc, commercial, industrial. Editing doesn't start immediately, but mostly after shooting is over. For those jobs I would just keep the audio until the end of the production, regularly backing it up off set on your laptop, then deliver batches of several or all days at once, burnt on DVDs or copied to cards from your laptop.

Talking to post about their needs and workflow might solve the problem without Zaxcom having to slab another slot on the Maxx?

[Derek H]

Glenn,

 

Thanks for clarifying. Can you elaborate on what it means for the MARF system to "write the directory only twice per recorded file" and why this is important?

 

Maybe Sound Devices' users can also comment on how the FAT32 system works in their devices, I'm under the impression that it does something to close the file every so often to minimize loss in the event of a crash or power failure but I don't know the details.   

[Zack]

Same result in the end, just a different path getting there, no mirroring though.

[glenn]

"Thanks for clarifying. Can you elaborate on what it means for the MARF system to "write the directory only twice per recorded file" and why this is important?"

 

If you were to have a reset/power issue while you were writing the directory it could be wiped out and that would lead to a media with unusable files. So the more often you write the directory the more likely it is that something really bad might happen. Because MARF embeds the directory directly into the audio data we only need to open the file and close the file once as was the intended way to use FAT32.  Doing it 1000s of times in order to try minimize a data loss in the event of a reset or power loss is in my opinion a bad way to do it.

 

Flash memory once upon a time had a burn out issue limiting the number of times it could be written before a memory failure. This is really not the case anymore but it is one of the reasons we chose to develop MARF.

 

Glenn

[dominiquegreffard]

I'd feel okay backing up a maxx card on a well protected cf card portable backup ssd drive before handing it out. That s the only workaround i can see. I wouldn t want to bring a computer every shoot really.

I ve seen a bunch for sale on the b&h website.

[Derek H]

Dominique, you mean the type of external hard drive that has a CF slot built in and can automatically copy the card?

That works but it will be time consuming as the drive will blindly copy the entire MARF directory too which, in the case of the Maxx, is half the size of your CF card. I'm working on a show now that uses one of those and I trained the data manager to backup my card manually to save time and drive space. I'm using 64GB cards so it's significant.

[Ze Frias]

Dominique, you mean the type of external hard drive that has a CF slot built in and can automatically copy the card?

That works but it will be time consuming as the drive will blindly copy the entire MARF directory too which, in the case of the Maxx, is half the size of your CF card. I'm working on a show now that uses one of those and I trained the data manager to backup my card manually to save time and drive space. I'm using 64GB cards so it's significant.

 

If doing daily cards per rolls, an 8GB card should suffice, and greatly reduce the time it takes for those drives to copy the data. However, if doing a single card for all daily rolls, then it will take longer. Additionally, you will continue get duplicates of all previous days for every new copy you do. These are all considerations for that workflow.

[pindrop]

As the thread is discussing archive and backup perhaps a useful ability for Zaxconvert to be updated with, would be to copy the relevant/used ZBLK0000.ZAX files which it can see, creating a MARF backup version on hard disk from the compact flash card?

But only the used ZAX files rather than the whole card which is filled up with ZAX files regardless of whether they are used or not. This would be a very useful capability for archive re-assurance.

It is possible of course to copy the whole MARF card as an archive but if it's a large card and only say a third of it was actually used it's time consuming and wasteful of space to have to copy all of the ZAX files, but I often do this anyway.

It seems that Zaxconvert is not far away from having this additional capability of creating a tailored to size MARF archive if you see what I mean.

Would anyone else find this useful?

[fieldmixer]

Anyone that owns or has used this piece of kit care to share their experience with it? It's dang pricy but would love to know practical details like the transfer speed to copy say, a 32gig CF card, battery life etc.

I would embrace the potential scenario where I could avoid the needing to pack a laptop and accessories to locations for simple data transfer. could be handy.

http://www.hypershop.com/HyperDrive/UDMA-2/

[macrecorder]

One of the problems of the Maxx system on the CF card is that there is no way to see the mirror WAV partition on the machine itself. So you cannot verify that the files have been extracted correctly from the MARF partition, or in the case of a partial extraction, that the correct files are there and complete. It would be much better if you could see this directory for verification before a handover. Why it is hidden from the user is one of those Zaxcom peculiarities which leaves you in the dark.

[pindrop]

One of the problems of the Maxx system on the CF card is that there is no way to see the mirror WAV partition on the machine itself. So you cannot verify that the files have been extracted correctly from the MARF partition, or in the case of a partial extraction, that the correct files are there and complete. It would be much better if you could see this directory for verification before a handover. Why it is hidden from the user is one of those Zaxcom peculiarities which leaves you in the dark.

Also true on the Nomad, I often have to hand over a compact flash cards immediately due to time pressure and actually have no idea whether the mirrored files are on the card or not.

It's hand off and hope, which doesn't seem very professional.

It would be very useful if there was a way to simply list what's on the card. Dare I say it, SD can do it easily, you just press a couple of buttons and there's a listing of what's on the CF card, which is very re-assuring.

[glenn]

One of the problems of the Maxx system on the CF card is that there is no way to see the mirror WAV partition on the machine itself. So you cannot verify that the files have been extracted correctly from the MARF partition, or in the case of a partial extraction, that the correct files are there and complete. It would be much better if you could see this directory for verification before a handover. Why it is hidden from the user is one of those Zaxcom peculiarities which leaves you in the dark.

 

There is zero possibility that the files will not be recorded correctly with a Zaxcom product. The MAXX tells you exactly how many files it has mirrored as its doing it. If the machine is shut down before a file can be recorded it will automatically restart the mirror at the correct file. You are never in the "dark" if you look at the number of files recorded vs mirrored.

 

Glenn

[macrecorder]

Not true. I had an instance where the Maxx insisted that the files had been mirrored (kept skipping over the segments I wanted mirrored - I think it had started to mirror and never finished). I handed over the card. Panic calls the next day - files missing. Pulled them out with zaxconvert. All a hassle easily avoided if we could see the mirror partition to ascertain if the correct files have been mirrored and are present. What is the problem with giving confidence to the users in letting them check the mirror partition's content? Even if it doesn't usually make such an error, it can still be the case that you want to extract only certain files, and need to check which ones you have done, or need to do yet. As pindrop says, it is professional to be able to verify the process. As it is, you are in the dark. It is hand over and hope for the best.

[Ze Frias]

Not true. I had an instance where the Maxx insisted that the files had been mirrored (kept skipping over the segments I wanted mirrored - I think it had started to mirror and never finished). I handed over the card. Panic calls the next day - files missing. Pulled them out with zaxconvert. All a hassle easily avoided if we could see the mirror partition to ascertain if the correct files have been mirrored and are present. What is the problem with giving confidence to the users in letting them check the mirror partition's content? Even if it doesn't usually make such an error, it can still be the case that you want to extract only certain files, and need to check which ones you have done, or need to do yet. As pindrop says, it is professional to be able to verify the process. As it is, you are in the dark. It is hand over and hope for the best.

 

Are you sure you were mirroring the right folder?

[Jack Norflus]

There is an option to select which files you want to mirror. My guess is you may not have had those files selected.

[macrecorder]

Well, nice of you all to determine that I had made a mistake. Wrong. There was only one folder, which was being recorded to and mirrored. The other files in that folder mirrored ok, and no changes were made. I know about the option to choose which files to mirror. Despite my suspicion that the files hadn't all mirrored (because of the suspiciously quick time it had taken to mirror long multitrack files), even when I reset the segment numbers to force mirroring (in order to be sure), the Maxx skipped over them - it had decided they were already mirrored. But they were not. So spare me the operator error stuff - there was a glitch, it didn't mirror as it was supposed, and as I emphasise, because of the operating system's lack of ability to see the mirror partition, there was no way of checking from the machine. I consider this to be a drawback of the machine, since it relies on one card only, when you need the WAV files more than the MARF ones. I suspect that it was overtaxing the processor with large multitrack files whilst recording, so it just gave up, but falsely flagged the files as having been mirrored. So it is a warning for others. This could be easily solved with the ability to see the WAV directory and the files therein.

[Ze Frias]

Take a breather man. No one is asserting that it is a mistake on your part, and that there are no possible faults with the device. I was just asking in case, as it is a possibility. No one is perfect, and even the best technicians can make mistakes. Either way, if you are still experiencing issues with WAV files not mirroring correctly, perhaps taking it to the nearest dealer or sending it back to factory for a check-up?

 

Every recorder has its advantages and disadvantages, and no one is denying that one of the disadvantages for many (it's always a matter of perspective, isn't it?) is that the Maxx only records to a single media. If this is a turn off for anyone, they should probably refrain from buying a Maxx then. That's the beauty about this, there are other options.

 

Just my two cents anyway. Cheers to you, and hope it all works out in the end.

[Jack Norflus]

I'm not going to say that it didn't happen because as our esteemed senator says "crap happens" - but what I can say is this is the first that I ever heard that a file wasn't mirrored that wasn't the result of a user error.

Though you should have reported this issue to Zaxcom so they can determine the if this was a software bug or a one time card glitch.

And just FYI if you re mirror a file Maxx will overwrite the previous file - it will not determine that the file is already mirrored and not write it.

And a sluggish processor will not cause a file not mirror or re-mirror - it will just slow down the mirroring speed.

[studiomprd]

Pretzelface: " the result of a user error. "

that's exactly what I was thinking, but I'm in Internet Rehab, here in the lovely rainbow room at Malibu...

" Though you should have reported this issue to Zaxcom so they can determine the if this was a software bug or a one time card glitch. "

ditto