Topic: Microtrack 24/96 Firmware 1.4.1b9 released

[eskin]

MicroTrack 2496

Version: 1.4.1 b9 (BETA)

Release Date: July 17, 2006

Applies to:
MicroTrack 24/96

Operating System(s):
Windows 2000, Windows XP, Mac OS 10.3.9, Mac OS 10.4.0, Mac OS 10.4.1, Mac OS 10.4.2, Mac OS 10.4.3, Mac OS 10.4.5, Mac OS 10.4.4, Mac OS 10.4.6, Mac OS 10.4.7

Release Notes:
This readme covers MicroTrack 24/96 Firmware v1.4.1b9

NOTE: This is a beta release. As such, we do not recommend using this release in a critical use environment. Such use is at your own risk.

If you experience any issues with this release, please use our beta release support form to report it at:

http://www.m-audio.com/index.php?do=support.betaform

============================================================
Installation Instructions:

1) Connect the MicroTrack 24/96 to your Mac or PC (Please refer to your manual for details on this procedure).

2) Copy the three files from this update, "PP5020.mi4", "BL_MPR.rom" and "Resources.arl," onto a properly formatted Compact Flash card to the root (top) directory of your MicroTrack 24/96 (Do not put them in a folder).

3) Properly unmount the MicroTrack 24/96 from the computer (Again, please refer to your manual for complete instructions).

4) On the MicroTrack 24/96, navigate to Main Menu > System > Firmware Update and press the NAV button.

5) You will be asked to verify this action. Press the NAV button again to begin the firmware update. The MicroTrack will show a few messages on the screen while the update is in progress. The four LEDs around the level controls will flash sequentially during the update. When the firmware update is complete, the MicroTrack will automatically reboot. To verify the firmware update was executed, go to Main Menu > System > Version. If the firmware update was successful, it should now show Firmware 1.4.1 b9 and Bootloader 1.02

============================================================

Changes from v1.4.1b2 (beta) to this release:

- Added a dialog (with animation) to notify a user when a file deletion is taking place.
- Added animation to the Writing file dialog to show it's progressing.

============================================================

Changes from v1.4.1b1 (beta) to v1.4.1b2 (beta):

- MP3 recordings would not play using Windows Media Player. Fixed.

============================================================

Changes from v1.4.0 to v1.4.1b1 (beta):

- When manually stopping a recording, if a second recording was started while the first was still being saved, the second recording wouldn't save to disk. Fixed.

============================================================
Note about deleting files:

We have seen that some media can cause the MicroTrack 24/96 appear to be frozen or stalled when you delete a large file. We have now added a dialog that shows you that the file deletion is taking place (a dialog with an animated hourglass). The delete process can take up to several minutes to complete depending on the size of the file being deleted (the longer the file the longer the time it will take) and the particular media being used. While it is completing, you will not be able to begin a new recording. Because of this, we recommend that if you know that you will be needing to begin a recording quickly, and you need to free up some space on your media, that you delete the files well ahead of the time of your recording session. Even on the fastest media, deleting the largest files (2GB) can take up to 30 seconds to complete. On our worst tested case we found media that took as long as 5 minutes to complete (though the overwhelming majority were much faster than this). Also, as a general rule, MicroDrives will take longer to delete files than compact flash media.

Tip: You can press the REC button while the file is being deleted and the MicroTrack will begin recording as soon as it finishes the delete operation (if you press the REC button a second time while the file is still being deleted, the recording will be aborted).

[JoeKiller]

I'll bite the bullet at 10klf.  Got a lappy so if the worst happens I can roll back.

BTW, the 1.4.1b2 worked flawlessly at allgood, stability wise, but it didn't pick up the frequency correctly through spdif thus making me change that.

edits for accuracy.

[dactylus]

 

  2GB autosplit?

 


  If not now, when?  Does anyone know if this is being worked on by M-Audio?  Are they taking that issue seriously?  I daresay that the rats abandoning the ship for the Edirol R-9 would have been fewer if this issue had been addressed before now.  With the exception of the 2GB autosplit I am content with the MT24/96.   

  Are you listening M-Audio?

[jtessier]

  2GB autosplit?

 


  If not now, when?  Does anyone know if this is being worked on by M-Audio?  Are they taking that issue seriously?  I daresay that the rats abandoning the ship for the Edirol R-9 would have been fewer if this issue had been addressed before now.  With the exception of the 2GB autosplit I am content with the MT24/96.   

  Are you listening M-Audio?

No, the word I got from the techs, is that it is as good (sic) as it's going to get until/unless they come out with a totally new product. So maybe a MT Mark II.

J.T.

[jtessier]

This isn't really beta 9 related but has anyone tried a PNY Optima 1GB 60x CF with the MicroTrack. A friend of mine had one and let me try it and the MT wouldn't recognize it.  It kept saying it was unformatted (even after having the MT re-format it).  My other cards work fine and the PNY seem ok under Windows. I've tried pretty much every card I've come in contact with and this is the first one I've had that did this.

J.T.

[batchain]

This isn't really beta 9 related but has anyone tried a PNY Optima 1GB 60x CF with the MicroTrack. A friend of mine had one and let me try it and the MT wouldn't recognize it.  It kept saying it was unformatted (even after having the MT re-format it).  My other cards work fine and the PNY seem ok under Windows. I've tried pretty much every card I've come in contact with and this is the first one I've had that did this.

J.T.

Same problem with PQI cards.

LT

[Nick Graham]

  2GB autosplit?

 


  If not now, when?  Does anyone know if this is being worked on by M-Audio?  Are they taking that issue seriously?  I daresay that the rats abandoning the ship for the Edirol R-9 would have been fewer if this issue had been addressed before now.  With the exception of the 2GB autosplit I am content with the MT24/96.  

  Are you listening M-Audio?

No, the word I got from the techs, is that it is as good (sic) as it's going to get until/unless they come out with a totally new product. So maybe a MT Mark II.

J.T.

While I'll be the first to admit I don't know jack about writing firmware or the technical ins and outs of the MT, I'm led to believe it has to be possible.

Until a couple of updates ago the deck would just stop when it reached 2GB, so programming it to start a new file (even with the 5 to 6 second pause) was a step in the right direction. One would think it wouldn't take too much to get it to do it seamlessly.

I've been primarily using my R1 simply because manually starting a new file is sooooooo much quicker than with the MT. If they can ever get a seamless file split I'll go back to the MT exclusively.

[Brian Skalinder]

While I'll be the first to admit I don't know jack about writing firmware or the technical ins and outs of the MT, I'm led to believe it has to be possible.

Until a couple of updates ago the deck would just stop when it reached 2GB, so programming it to start a new file (even with the 5 to 6 second pause) was a step in the right direction. One would think it wouldn't take too much to get it to do it seamlessly.

The auto-save/close/start-a-new-file is simply an automation of a manual process that's already supported - not hard to do, really.  The challenge with the seamless split is probably related to a buffer that's too small to handle the data while the old file closes and a new one starts.  Just a guess.

That said, a nice improvement would be recording L and R mono files to enable double the run-time before needing to start a new file.

[jmz93]

Ok, so if the MT is pretty much as good as it's going to get, here are a couple questions from a non-techy person. 
1. What CPU/OS is implemented in the Microtrack?
2. If it's similar to that used in portable mp3 players, could rockbox be made to work with the Microtrack???
3.  Again, I'm no programmer, but what language did they probably use to write the firmware?  In the old pre-Windows pc days, assembler was the thing for super-fast execution times, minimal memory usage, etc. you know, back when memory was measured in 4MB or less, and saving 50-100K by writing in a lower-level language was a real advantage? 

Could something be ported to run on the Microtrack written in a language closer to machine code? I'd certainly trade in the stupid animations and things for snappier performance, not to mention faster boot times!!!
This thing crawls along compared to the R9, and if it wern't for the S/PDIF and the money I've already spent on CF cards and the Microtrack itself, I would switch!
*sigh* Ok, I feel better now ... thanks for reading.

[dmaster]

well, it's great to know that they're working on animated dialog boxes.   I mean that was the biggest complaint with the thing right?  Animated dialog boxes?  Everything awesome has animated dialog boxes, right?    This totally makes the MT a professional product, hands down. 

I mean who wants a battery meter that doesn't suck, and files that don't cut off at 2GB?  That stuff is for nerds and weirdos, all the cool kids want animated dialog boxes. 

[jtessier]

well, it's great to know that they're working on animated dialog boxes.   I mean that was the biggest complaint with the thing right?  Animated dialog boxes?  Everything awesome has animated dialog boxes, right?    This totally makes the MT a professional product, hands down. 

I mean who wants a battery meter that doesn't suck, and files that don't cut off at 2GB?  That stuff is for nerds and weirdos, all the cool kids want animated dialog boxes. 

Well I assume they must had had some complaints about how with previous versions when you deleted a big file and then hit the rec button to grab a new recording it would sit there like a rock. It happened to me with a MicroDrive and I thought the thing was frozen (not a surprising conclusion given the MT's history).  I force powered off but just as it went off I saw it switch to record mode.  I repeated the sequence once it booted and sure enough it was just taking forever to finish up deleting. I think the change was just a fix for a reported problem that since it was fairly easy for them to fix they did it.  They didn't have to they could have just either 1) ignored it or 2) put out some lame tech note explaining that users should just cool their jets after deleting files. I'm happy that they at least took the time to enhance the interface to give the user the info that the device is busy. The MT is by no means perfect but for me it's just fine. If I had a need to seamless splits I'd probably be less happy though.

P.S. I thought someone had posted info about the processor the MT uses and had said that they believed that it didn't have the horsepower to do seamless splits.

J.T.

[dactylus]

While I'll be the first to admit I don't know jack about writing firmware or the technical ins and outs of the MT, I'm led to believe it has to be possible.

Until a couple of updates ago the deck would just stop when it reached 2GB, so programming it to start a new file (even with the 5 to 6 second pause) was a step in the right direction. One would think it wouldn't take too much to get it to do it seamlessly.

The auto-save/close/start-a-new-file is simply an automation of a manual process that's already supported - not hard to do, really.  The challenge with the seamless split is probably related to a buffer that's too small to handle the data while the old file closes and a new one starts.  Just a guess.

That said, a nice improvement would be recording L and R mono files to enable double the run-time before needing to start a new file.

Brian - Have you suggested this to the M-Audio folks?  If insufficient buffer size is the hangup then your suggestion makes perfect sense to me.  I like the MT24/96, even with the warts, but the 2GB filesize gremlin is definitely one that I'd like to see addressed...

[dmaster]

P.S. I thought someone had posted info about the processor the MT uses and had said that they believed that it didn't have the horsepower to do seamless splits.

horsepower is meaningless.   It's a formatting issue.  (technically a filesystem issue, but the root of the problem is the same). 

They're using a filesystem that only allows for 2GB files, presumably to reduce the overhead or something in that nature of efficiency.   The last time I had something like this affect me, I was using Windows95.   Meanwhile, technology has ramped up to the point where you can magically save larger than 2GB files on modern platforms, but the MT was developed with 10-year old filesystem technology.   Woo hoo! 

It's really an issue of using a signed rather than an unsigned value for their file pointers, which is a limitation of the ancient FAT-16 filesystem.    FAT-32 goes up to 4gb/file. 

It boggles my mind why they haven't made the system compatible with something, or why they developed their own filesystem with such a limitation, but it's very sad. 

[Brian Skalinder]

Brian - Have you suggested this to the M-Audio folks?

Multiple times.

[jtessier]

P.S. I thought someone had posted info about the processor the MT uses and had said that they believed that it didn't have the horsepower to do seamless splits.

horsepower is meaningless.   It's a formatting issue.  (technically a filesystem issue, but the root of the problem is the same). 

They're using a filesystem that only allows for 2GB files, presumably to reduce the overhead or something in that nature of efficiency.   The last time I had something like this affect me, I was using Windows95.   Meanwhile, technology has ramped up to the point where you can magically save larger than 2GB files on modern platforms, but the MT was developed with 10-year old filesystem technology.   Woo hoo! 

It's really an issue of using a signed rather than an unsigned value for their file pointers, which is a limitation of the ancient FAT-16 filesystem.    FAT-32 goes up to 4gb/file. 

It boggles my mind why they haven't made the system compatible with something, or why they developed their own filesystem with such a limitation, but it's very sad. 

You're talking about a different (though certainly related) issue.  I'm saying I thought I read that the chip couldn't do seemless splits between two files. Your saying that the filesystem doesnt' support 4GB files. Both are solution to the same problem but I was only mentioning that I had thought someone had written that they believed that the hardware may not support one of the solutions (seemless splits). I don't really know enough about file systems to comment about the other solution (4GB files). About the only thing I can say about that is that if it supported 4GB files, someone would still complain about it not doing seemless splits where if it did seemless splits there wouldn't be much (I think) of an outcry about it not doing 4GB files since it's wouldn't really be 'neccessary'.

J.T.