Topic: Microtrack 24/96 Firmware 1.4.0

[BC]

I found problem with deleting a file as the deck will not (at least) record after file deletion.  It 'acts' like it will record, but NO new file is created. 

Deleted file is gone, but no new file is possible until reboot is performed. 

This was not the case with previous v1.2.3 (never loaded v1.3.3)

should definitely report this to m-audio tech support.
Finding new bugs with each new firmware release is such a PITA with this thing. 


Thanks for letting us know that you have to wait for the original file to finish recording before starting a new one, that is an important tip. At least it does not take that long for the files to save.

[udovdh]

I found problem with deleting a file as the deck will not (at least) record after file deletion.  It 'acts' like it will record, but NO new file is created. 

Deleted file is gone, but no new file is possible until reboot is performed. 

This was not the case with previous v1.2.3 (never loaded v1.3.3)

Please keep us updated when you mention this to the M-Audio support.

(please mention the 2GB bugs as well: 2.000.000.000 versus real 2GB and seamless autosplit)

[pjdavep]

Anyway, there seems to be a small loss of functionality with 1.4.0 which if you're not careful will cause you to lose data.  Previously, to start a new file on the fly, you could just hit the Rec button twice quickly, and it would write the current file and instantly start the new one.  Well now if you do that... it writes the first file alright, and gives the appearance of starting a new one, but the file number doesn't advance, and in the time remaining box it shows the length of the file you just recorded instead of time remaining on the card or file.  Meanwhile it still looks like it's recording - it still receives signal (I checked later with monitoring), and the timer counts away.

But when you press Rec again to write the second file, it just stops with no writing file message.  Check the files and it's not there either.  But - the file number was assigned - start another file, and a gap appears in the file numbering sequence.

So after all that, I found that now, you must *not* start the new file until the current one has finished writing and the MT has returned to a 'stopped' state.

Crap, this happened to me last Wednesday night at an Ours show, and I am missing the last two songs   I used the tap REC button twice method, and when I got home, my files were numbered 58, 59, and 61.  File 61 was about 3 seconds of silence (61 must have occurred at the end of the show when I went to stop the recording that I thought was being made).  So it skipped a number and recorded nothing after that.  Since I had some apparent cable problems that night, I was going to do some testing at home prior to calling it a bug.  This is officially the first problem that I have personally encountered while using the MT, so I'm not that pissed, but how can you miss that in QA testing??

Later,
   pjdavep

[it-goes-to-eleven]

I can possibly try and recover these shows (if they are good/important) but I'd need the entire contents of the CF card copied to a dvd.  It would involve searching for the WAVE header in the raw data or just examining the raw data, etc.

Ultimately, though, m-audio should be sending out a program (or method) that finds the 'lost' audio on the cf and recovers it.  Call them and demand it.  When they pushback, ask for a supervisor and keep going up the chain.

Ultimately though, m-audio sucks and they don't seem to 'get it'. Maybe we need to get the contact info for the CEO or register m-audiosucks.com to draw some attention to their repeated suckage.

[pjdavep]

I can possibly try and recover these shows (if they are good/important) but I'd need the entire contents of the CF card copied to a dvd.  It would involve searching for the WAVE header in the raw data or just examining the raw data, etc.

+T for the offer, but I wiped it clean for a show on Friday night.  Prior to reading the new posts in this thread, I was thinking that it was something I had done 

Later,
  pjdavep

[JoeKiller]

Ultimately though, m-audio sucks and they don't seem to 'get it'. Maybe we need to get the contact info for the CEO or register m-audiosucks.com to draw some attention to their repeated suckage.

What suckage is repeating?  It seems to me that they are hammering out the bugs to the best of their ability. 

[it-goes-to-eleven]

What suckage is repeating?  It seems to me that they are hammering out the bugs to the best of their ability. 

1. Their testing is piss poor.  Critical bugs that result in the loss of recordings are the norm in each release.  These are bugs that would have been found during even a fairly limited testing program.

2. No follow-up on critical bugs.  When those critical bugs are reported by large numbers of users, they don't follow-up with a quick release that corrects the critical bugs. Instead they wait months until the next regular release.

[rodeen]

I ran 1.4.0 last night for the first time.  Goran Ivanovich Group.  I ran 2, 1 hour sets at 24/48.  No explosions, fires, etc. Recording sounds great.  Everything worked well but this was as straight forward of a setup as you can get. 

Made sure we had a fire extinguisher handy and that everyone had an escape route planned. 

[coloartist]

Thanks for the testing, kids. I am staying with 1.2.3.

It works fine.

[jtessier]

Thanks for the testing, kids. I am staying with 1.2.3.

It works fine.

For me with the amount of S/PDIF issues that were fixed and the fact that this new bug looks to be easily (in most cases) avoidable, I'm sticking with 1.4.0. I'll just be careful to not to quick back to back recordings.

Also, for those interested, I did a quick test and found the following:

If you do encounter this bug you can tell by two symptoms;

1). The time counter will be incrementing up to the length of the previous file instead of incrementing up to the 2GB file limit. 

2). The file name will not have incremented. 

So if you just did a recording to file 0259.wav for 30 minutes then you stop and start a new one and it shows you again recording to file 0259.wav and it shows that it will stop in 30 minutes (even though you are recording to a volume with at least 2GB free) then you know that you just ran into the problem. So keep a careful eye on the file name when you stop and start new recordings. Make sure it increments. To me this would be much worse if instead of not saving the new recording it was actually overwriting the old one.  That would really really be nasty.

J.T.

[svenkid]

I dont know if this is  a bug or not, but Im running 1.1.5 firmware, using a kingston 4g card

All the files are deleted, but it shows that there is still a .5g file somewhere. I keep trying to find it and erase it, but its nowhere to be found. could this be a  cf issue?

[jtessier]

I dont know if this is  a bug or not, but Im running 1.1.5 firmware, using a kingston 4g card

All the files are deleted, but it shows that there is still a .5g file somewhere. I keep trying to find it and erase it, but its nowhere to be found. could this be a  cf issue?

Hmmmm. Does formatting it using the MicroTrack get rid of it?  While I don't know if 1.1.5 had a bug like that, 1.2.3 and later didn't as far as I recall.

J.T.

[Judderbar]

Just a small point of order... It's not necessarily a bug, unless they advertise this feature. If it just happened to work before, and now just doesn't, that is too bad.

Not that I'm trying to stick up for these guys, but there is a lot of verbiage flying around and we gots to be careful what we says.

hiRes

If the second button push had no effect and when it finished writing the first file it just stopped, then I could accept it as simply a change.  But when it looks like it's recording and then you find out it wasn't, then I think we can safely call it a bug...

If only m-audio would have a single person with a clue spend 8 hours testing these reseases, they would be a lot better.  This is just pathetic.

Well... check out my experience with m-audio UK tech "support":

Sent a message via the website describing what happened, and got an email back from a UK Tech Support person saying that there was probably a quick solution and to phone tech support.  So I phone and start talking about the email... and the bloke on the other end asks me to forward my original message to him!  I said "But you're tech support - surely you already have it??"  He got a little annoyed then, saying that of course if he had it he wouldn't be asking for it, and never got to see messages sent to the website.  But said he would send it on to the USA for them to check out.  So now just waiting to see if I get any further response.


But the question I still have is - when the MT is recording the phantom file, is anything actually being written to the card?  Is there anything to salvage or should I just give up and reformat?  I've not managed to recover anything off the card I recreated the problem on...

I can possibly try and recover these shows (if they are good/important) but I'd need the entire contents of the CF card copied to a dvd.  It would involve searching for the WAVE header in the raw data or just examining the raw data, etc.

Thanks for the offer (if also directed at me), but see above - need to find out if there's anything to recover...
 
 

[Howell]

But the question I still have is - when the MT is recording the phantom file, is anything actually being written to the card?

The microtrack has no other memory in the device large enough to hold the recording so whenever it's recording it would have to be writing to the card.  Of course I guess there could be a small buffer where a little bit could be lost in the event of an abruptly stopped recording, but it woudl be a small part of what you were recording.

[beanstalk]

I guess I'm going to stay with the 1.3.3 from what I've been reading here.