Home |
Search |
Today's Posts |
#1
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
I thought I was doomed.
Just finished shooting the second half of Mulan, a stage play that we were hired to shoot. Used the Zoom on a tripod to get the up-front sound from the stage. First half, worked flawlessly. Second half complete, shut down the camera and go down to retiieve the recorder. It was put in the HOLD position for recording so that no one could shut it off on me. So what happens when you try to stop recording or any other operation is that it tells you you are on the HOLD position and must rmove the HOLD if you need to do some task on it. Well, if you move the HOLD button down, you arrive in the SHUT DOWN BYE SEE YA position, which is what happened. Then I started sweating because I thought it didn't have time to transfer the data to the memory card before shutting down. Super bad trend if they are trying to eliminate complicated usage instrucions. But it DID transfer all the data. Beautiful recording of the close-up dialog on stage, which was very hard to hear in the audience due to a cheap sound system. So now the video will have better sound than the play did live. I used a touch of compression in Audition in editing, but the sound on AGC was very good anyway. Saved the video. Also did a surround sound recording of a dance band with the Zoom. Used 3 spaced omnis (AT 2050) for the front, Zoom MS for the rear. Worked quite well technically, but quite a pain to edit and convert to DTS surround files. Not the best example either, with very small audience & hardly any rear sound to listen for. Anyway, a good report on an inexpensive little "non - professional" recorder as discussed above doing a job for me and coming through even with operator screw-ups. Gary Eickmeier |
#2
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Gary Eickmeier writes:
Well, if you move the HOLD button down, you arrive in the SHUT DOWN BYE SEE YA position, which is what happened. Then I started sweating because I thought it didn't have time to transfer the data to the memory card before shutting down. I'm sure that the switch isn't really any kind of on/off switch. It would just send a signal to the OS to start shutdown. And writing any remaining data out to the card would be a standard action for the OS before it actually shuts down. Any kind of gadget that shut down without writing out all updates to files would be a really bad design. |
#3
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Mxsmanic" wrote in message ... Gary Eickmeier writes: Well, if you move the HOLD button down, you arrive in the SHUT DOWN BYE SEE YA position, which is what happened. Then I started sweating because I thought it didn't have time to transfer the data to the memory card before shutting down. I'm sure that the switch isn't really any kind of on/off switch. It would just send a signal to the OS to start shutdown. And writing any remaining data out to the card would be a standard action for the OS before it actually shuts down. Any kind of gadget that shut down without writing out all updates to files would be a really bad design. Sure - agreed - but I was composing the fattest letter to Zoom on the design flaw on the drive home while sweating the recording. Normally, especially on a long recording, when you press the Stop recording button, you get a screen that says Please Wait... and it takes a few seconds to finalize, write to card, whatever it needs to do to finish the process and get ready for the next recording. This time, I drew the HOLD slider button down, and it immediately said Bye See Ya (the cute little shut down language) and it was outa here. No waiting period. All I can conclude is that it just says that, but internally it is writing and finalizing whatever it has to do to finish the file, unbeknownst to the hapless schmuck who just got lured into shutdown from Hold. Bottom line, competernt design - actually a very clever little recorder - even if it is not a "Pro" recorder as was discussed in a thread above. Gary Eickmeier |
#4
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Gary Eickmeier" wrote in message om... Sure - agreed - but I was composing the fattest letter to Zoom on the design flaw on the drive home while sweating the recording. Normally, especially on a long recording, when you press the Stop recording button, you get a screen that says Please Wait... and it takes a few seconds to finalize, write to card, whatever it needs to do to finish the process and get ready for the next recording. This time, I drew the HOLD slider button down, and it immediately said Bye See Ya (the cute little shut down language) and it was outa here. No waiting period. All I can conclude is that it just says that, but internally it is writing and finalizing whatever it has to do to finish the file, unbeknownst to the hapless schmuck who just got lured into shutdown from Hold. Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? If anything is being done it's not to do with saving what you've just recorded. Most digital recorders you can pull the plug (batteries) half way through, and still keep what you've recorded up till then. (caveat I don't own a H2n so have no idea if they do what most of the others do) Trevor. |
#5
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Trevor" wrote in message ... Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? If anything is being done it's not to do with saving what you've just recorded. Most digital recorders you can pull the plug (batteries) half way through, and still keep what you've recorded up till then. (caveat I don't own a H2n so have no idea if they do what most of the others do) Trevor. Does anyone know what it is doing during the "Please Wait" period? Gary Eickmeier |
#6
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Trevor writes:
Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? Data is probably held in an internal buffer before being written to the card. This buffer must be flushed to the card before the system is shut down, in order to avoid any loss of data. Depending on the size of the buffer and other factors, there may or may not be a perceptible delay when the buffer is flushed. An experiment to demonstrate this would be to pull the batteries out while the recorder is recording sound, although that's not an experiment that I intend to carry out. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. |
#7
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Gary Eickmeier writes:
Does anyone know what it is doing during the "Please Wait" period? Probably flushing buffers and doing other operations on the memory card. I note that the longer the recording, the longer the "please wait" period, although it's not a linear correlation. |
#8
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Mxsmanic wrote:
Trevor writes: Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? Data is probably held in an internal buffer before being written to the card. This buffer must be flushed to the card before the system is shut down, in order to avoid any loss of data. Depending on the size of the buffer and other factors, there may or may not be a perceptible delay when the buffer is flushed. An experiment to demonstrate this would be to pull the batteries out while the recorder is recording sound, although that's not an experiment that I intend to carry out. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. It flushes the recording buffer to RAM and updates the FAT, which is normally held in RAM while the machine is working. As they don't use a journalling file system, the information on where to find the file blocks can get out of sync with where they actually are. If they used something like extf3 or reiser FS, it wouldn't be an issue, but Windows would be unable to read the SD card directly. The H2 has a few seconds of buffer available which can be used as a pre-record buffer in live situations so you don't miss the first few seconds of a vital recording, as it records from 10 seconds before you press Record. In this case, the last 10 seconds has to be written to the card before it can shut down. -- Tciao for Now! John. |
#9
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Mxsmanic" wrote in message ... Trevor writes: Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? Data is probably held in an internal buffer before being written to the card. A relatively small amount, a few seconds worth at most. This buffer must be flushed to the card before the system is shut down, in order to avoid any loss of data. Depending on the size of the buffer and other factors, there may or may not be a perceptible delay when the buffer is flushed. Closing a file also requires some kind of table of contents entry to be updated, and there may be some work needed along the lines of updating file allocation tables. An experiment to demonstrate this would be to pull the batteries out while the recorder is recording sound, although that's not an experiment that I intend to carry out. If the media is removable, see what happens when you simpy pull that out. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. Not necessarily. There can be a big capacitor inside the box that keeps it alive long enough for housekeeping to finish. |
#10
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
On 3/26/2012 7:03 AM, Arny Krueger wrote:
Closing a file also requires some kind of table of contents entry to be updated, and there may be some work needed along the lines of updating file allocation tables. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. It's possible that the housekeeping is writing something to the card that allows the recorder to find and play the file. So it may not be playable from the recorder, but as long as the WAV file was properly written to the card, it would be playable with a computer as long as the card still looked like a disk drive. -- "Today's production equipment is IT based and cannot be operated without a passing knowledge of computing, although it seems that it can be operated without a passing knowledge of audio." - John Watkinson http://mikeriversaudio.wordpress.com - useful and interesting audio stuff |
#11
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Mxsmanic" wrote in message ... Trevor writes: Surely it's just writing to the card all along, so why would you expect it to take a few seconds to "finalise" anything before "writing to the card"? Data is probably held in an internal buffer before being written to the card. This buffer must be flushed to the card before the system is shut down, in order to avoid any loss of data. Depending on the size of the buffer and other factors, there may or may not be a perceptible delay when the buffer is flushed. An experiment to demonstrate this would be to pull the batteries out while the recorder is recording sound, although that's not an experiment that I intend to carry out. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. Another good example is digital cameras. Notice that if you take a picture that requires some processing in camera, it can take a while. All photographers know that the basic process is it records to internal memory, then writes to the card. If the internal memory is too small, you have to wait a while after shooting a burst of exposures. I'm supposing that if you pulled batteries or similar then you would lose your pictures. If a digital recorder works by constantly writing to card, then that would be great, because you would not lose much if batteries failed etc. Gary Eickmeier |
#12
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Mike Rivers" wrote in message ... On 3/26/2012 7:03 AM, Arny Krueger wrote: Closing a file also requires some kind of table of contents entry to be updated, and there may be some work needed along the lines of updating file allocation tables. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. It's possible that the housekeeping is writing something to the card that allows the recorder to find and play the file. Yup, and us computer nerds call those things that help find and play files, "tables of contents". ;-) So it may not be playable from the recorder, but as long as the WAV file was properly written to the card, it would be playable with a computer as long as the card still looked like a disk drive. On CDs, unclosed media is called a CD that is not finalized. The good news is that I have 95%+ success finalizing the unfinalized CDs fall into my hands. DVDs, not so much, but usually I have better success if I can get access to the recorder that wrote the disc. On USB flash drives, unfinalized media is generally not observable. The flash drive itself may keep itself alive long enough to do the needed steps when you unplug is, or it may use a file system that allows the finalization to be done automatically the next time you plug it in. USB flash drives usually have a fairly powerful 32 bit computer in their USB interface that preserves the illusion that it is dumb, but friendly media. In fact flash is not especially nice to work with, but its bad habits are well known and concealing them is a very highly developed art. |
#13
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
John Williamson writes:
It flushes the recording buffer to RAM and updates the FAT, which is normally held in RAM while the machine is working. As they don't use a journalling file system, the information on where to find the file blocks can get out of sync with where they actually are. If they used something like extf3 or reiser FS, it wouldn't be an issue, but Windows would be unable to read the SD card directly. NTFS supports journals, but I assume it must be more complex to implement than most vendors would like. Also, I suppose that FAT32 is probably understood by way more non-Windows operating systems than NTFS. Other journalling file systems tend to be even more exotic and are thus even more problematic to support. |
#14
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Arny Krueger writes:
A relatively small amount, a few seconds worth at most. Well, it takes several seconds to finish. Maybe it's just the speed of the card. Closing a file also requires some kind of table of contents entry to be updated, and there may be some work needed along the lines of updating file allocation tables. Yes. If the media is removable, see what happens when you simpy pull that out. If there is indeed a buffer flush, the card content is likely to be corrupted if the batteries are removed while recording is in progress. Not necessarily. There can be a big capacitor inside the box that keeps it alive long enough for housekeeping to finish. True. But I'll leave both experiments to someone else with more money than I have. I actually did make the mistake of turning the H4n off today while it was still writing out the (very long) sound file that I had just recorded, but the file was still recorded correctly, so obviously it finished up what it needed to do before shutting down. Of course, most operating systems work that way as long as you don't turn the power off or hit a hardware reset button. |
#15
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Mxsmanic wrote:
NTFS supports journals, but I assume it must be more complex to implement than most vendors would like. Also, I suppose that FAT32 is probably understood by way more non-Windows operating systems than NTFS. Other journalling file systems tend to be even more exotic and are thus even more problematic to support. NTFS is totally undocumented. Everyone outside Microsoft who has implemented NTFS has done so through reverse-engineering the filesystem format. The quality and performance of the reverse-engineering continues to improve but none of the third-party NTFS implementations are anywhere near up to the level that I would trust a job with. ntfs3g is getting there fast, though. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#16
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Gary Eickmeier" wrote in message news Another good example is digital cameras. Notice that if you take a picture that requires some processing in camera, it can take a while. All photographers know that the basic process is it records to internal memory, then writes to the card. If the internal memory is too small, you have to wait a while after shooting a burst of exposures. Not a good example, since cameras often have high speed buffer memory to allow you to take faster burst rates than the card can handle. After a burst the data must be written to the card which can take time. When recording audio of more than a few seconds duration however, the data is streamed directly to the card, and any buffer is usually quite small. I'm supposing that if you pulled batteries or similar then you would lose your pictures. Yep. If a digital recorder works by constantly writing to card, then that would be great, because you would not lose much if batteries failed etc. And HAS to since most audio recordings are FAR to big for the buffer memory. Trevor. |
#17
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Mxsmanic" wrote in message ... I actually did make the mistake of turning the H4n off today while it was still writing out the (very long) sound file that I had just recorded, but the file was still recorded correctly, so obviously it finished up what it needed to do before shutting down. Of course, most operating systems work that way as long as you don't turn the power off or hit a hardware reset button. Interesting. But I suppose it is a different story if you remove the flash drive or memory card from the computer before the little icon says "Safely Remove" - right? Gary Eickmeier |
#18
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
"Gary Eickmeier" wrote in message .com... Interesting. But I suppose it is a different story if you remove the flash drive or memory card from the computer before the little icon says "Safely Remove" - right? Depends. I've been pulling USB memory sticks from the computer for many years without going through the "safely remove" bit, but making sure it's not during a write. Never had a single problem. If you pull one during a write, you may lose data and possibly need to fix the file table as well. Trevor. |
#19
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Gary Eickmeier writes:
Interesting. But I suppose it is a different story if you remove the flash drive or memory card from the computer before the little icon says "Safely Remove" - right? Yes. There's no way for software to bypass a hardware change. Once the contacts slide out of the slot, communication is lost, so if the changes haven't been written to the card, you have a serious problem. The same is true for removing the power, although what seems like an instant loss of power to a human being can often still provide useful power for a fair amount of work inside a computer. Many systems can execute short emergency-shutdown routines with just the power that remains if a power cut is detected. This may not extend to the slower and more power-hungry operations of physically writing to a disk or card, though. |
#20
Posted to rec.audio.pro
|
|||
|
|||
Saved by the Zoom H2n
Trevor writes:
Depends. I've been pulling USB memory sticks from the computer for many years without going through the "safely remove" bit, but making sure it's not during a write. Never had a single problem. If you pull one during a write, you may lose data and possibly need to fix the file table as well. Most computers will write to the USB key as soon as practical, so unless you literally pull the key while it's being written to, you're safe. Usually the few seconds that elapse between the last operation you perform on the key and your hand reaching for the key are enough for all writes to be completed. Most systems will not configure removable devices for write-into caching, especially things like USB keys, so physical writes are initiated immediately. |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Balanced power may have saved my butt | Pro Audio | |||
CoolEdit Pro 2.1 VBR163 encoded mp3 saved as 48 kbit mp3. Why? | Pro Audio | |||
CoolEdit Pro 2.1 VBR163 encoded mp3 saved as 48 kbit mp3. Why? | Tech |