badgerblog - Marantz PMD-620 shutdown at end of battery life
[Recent Entries][Archive][Friends][User Info]
11:16 am
[Link] |
Marantz PMD-620 shutdown at end of battery life
While at lunch with anthropologists (waves hello) a few weeks back we talked about portable field recorders, which I use for soundscapes and they use for interviews and ethnographic research. I was asked what happens to a sound file with my Marantz PMD-620 if the batteries died during a recording - was the active recording lost completely (the behavior of my previous M-Audio Microtrack and Microtrack II field recorders) or would the recorder save the file as part of a graceful shutdown?
The answer was a bit complicated. I took the recorder, hit Record, and made a note to check in a few hours. A while later I had a dead battery and a 3.7GB WAV file. Drag and drop to QuickTime, and no sound. The file showed as no time length at all. Ok, try it with Audacity, my first audio software of choice in general, and the file displayed as zero time. Try Audacity again and "Import Raw Data", which is how I make music from JPG and GIF image files [1] - tell Audacity what parameters and it will open the file as an audio file. A long while later I had a visible audio spectrum in Audacity. I had mis-set the import parameters so the recording was horribly distorted, but my talking on the recording at the beginning was vaguely recognizable as human speech. I saved out the first eleven minutes as a harsh noise track:
1011 - 11minutes0seconds. Harsh noise. Marantz PMD-620 field recorder, Audacity in importing raw data mode with inappropriate parameters.
Harsh noise. Do not turn the sound all the way up, especially on headphones, unless you like to fall asleep listening to Merzbow. Sounds vaguely like the message from the other side of the black hole in _Event Horizon_, actually. I should take this and try reverse engineering it using Sound Soap to clean out the noise and speed up the track until it's intelligible.
OTOH I now can *make* that kind of unintelligible message audio and reverse-engineer it in real-time, providing a sample, a performance routine, or a casual cryptographic technique for audio. Bonus!
ADDED later: the vocals are around 6 seconds in through about 25 seconds in, and remind me of the mostly-forgotten SF author M.A. Foster of Greensboro NC, specifically reminding me of his novel _Waves_ which received a review summarizing it as "nothing happens but it's very exciting", if I remember correctly. Foster is one of those authors who I buy extra copies of to have loaner copies, as until very recently all of his works were out of print.
[1] And I always think of that Philip K Dick short story where a programmer-musician encodes classical music as beetles in order to preserve the music should humanity destroy itself (he forgets about mutation as part of reproduction).
Tags: phonography, reads, sample, subscape annex
|
|
| |
Pretty cool, but ...
I had mis-set the import parameters so the recording was horribly distorted
If you had set the import parameters correctly (or differently?) would you have been able to get back the non-harsh-noise original recording that never had a fclose() done on it?
![[User Picture]](http://l-userpic.livejournal.com/4486/7632) | | From: | badger |
| Date: | July 8th, 2009 05:16 pm (UTC) |
|---|
| | | (Link) |
|
Good question, I don't actually know, I am hypothesizing based on the quality of the distortion sounding to me like a mis-set import parameter, akin in part to playing a 45rpm at 33rpm. I admit I didn't explore that further - once I had a file at all, and something that was recognizably English recovered from the power-dead condition, I made the assumption that I had merely chosen the wrong parameters and that the correct ones would result in an accurate import. I confess that I stopped there partly because it took Audacity's Import Raw Data command roughly 30 minutes to import the 3.7GB file. I should go back and verify that, perhaps with a new recording and much deader batteries to create a smaller data file.
Which number Sysadmin Rule is it that says to test your recovery scheme before you need it? *grin*
And I fully understand stopping where you did due to timing. Since there's no file size with the 3.7GB file, I wonder if you could slice off a chunk to play with Audacity settings with no ill effects in the final output. (Would save time and battery-death-guessing.)
![[User Picture]](http://l-userpic.livejournal.com/4486/7632) | | From: | badger |
| Date: | July 8th, 2009 05:35 pm (UTC) |
|---|
| | | (Link) |
|
EXACTLY. :) That's Rule #74. (#73 is "Backups are gold.") This was exactly the point of the test - I didn't need *this* recording, but a friend of mine who has done graduate research in ethnomusicology in Tibet (for a non-hypothetical example) could have been terribly inconvenienced by losing an interview before he transcribed it.
I carefully read through the user manual, the troubleshooting section, and the support section of the company's website, then did some google searches and found no answer to "what happens to a recording if the battery dies during the recording session?"
(Posting this is to record (snark) the results of the preliminary test as guardedly positive with a potential recovery strategy for the future benefit of others.)
![[User Picture]](http://l-userpic.livejournal.com/43200359/184121) | | From: | vuzh |
| Date: | July 9th, 2009 01:02 am (UTC) |
|---|
| | | (Link) |
|
I wonder if the original file might have been missing header information. If the file had been an AIFF, there's a program for it called Fix16BitAIFF.
![[User Picture]](http://l-userpic.livejournal.com/4486/7632) | | From: | badger |
| Date: | July 9th, 2009 02:13 am (UTC) |
|---|
| | | (Link) |
|
Unless Fix16BitAIFF runs on OS X that's not going to help me, thanks.
![[User Picture]](http://l-userpic.livejournal.com/3659/6675) | | From: | gyre |
| Date: | July 9th, 2009 06:39 pm (UTC) |
|---|
| | | (Link) |
|
The incomplete header is most likely, it being a WAV file. I've found the file format is one that requires you to go back to the header and update it on close or else on every write. You can write it out in segments but the segments are meta data and not chunking audio.
That's probably why the size came back at zero. The rest of the header might have been correct or it may have been lazy and just reserved the space and not written the header at all.
I used to have a C++ class for reading and writing WAV files that I used for a VoIP app I worked on. We used to read in WAV files to use as ring tones (but that I could have done without my own class) and save voicemail as WAV files. I haven't messed with Objective C much past "Hello World" though. Probably would have worked with the old Metrowerks CodeWarrior C++ compiler.
![[User Picture]](http://l-userpic.livejournal.com/4486/7632) | | From: | badger |
| Date: | July 9th, 2009 08:16 pm (UTC) |
|---|
| | | (Link) |
|
Hmm, interesting. I was just happy I found a workaround for the data before I needed to do it. |
|