Taperssection.com
Gear / Technical Help => Recording Gear => Topic started by: eskin on July 17, 2006, 07:35:54 PM
-
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).
-
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.
-
2GB autosplit?
:banging head:
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. ;D
Are you listening M-Audio?
-
2GB autosplit?
:banging head:
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. ;D
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.
-
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.
-
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
-
2GB autosplit?
:banging head:
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. ;D
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.
-
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.
-
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.
-
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, 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.
-
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...
-
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 - Have you suggested this to the M-Audio folks?
Multiple times.
-
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.
-
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.
Absolutely right. 4GB works for me if I'm running 24/44.1 but if I want to go 24/96 it's only two hours, which won't work for me in a stealth situation. I am now using a Sony D1, which does do seamless autosplits at 2GB. The D1 has 4GB internal memory and takes memory stick pro, but will not seamlessly switch from internal to memory stick, and I am really looking forward to the 8GB memory sticks due out any time now. So farit's the only pocketable 24/96 machine with autosplit (well, none of MY pockets will hold a 722).
The D1 does make great tapes at 24/44.1, better than the R1 I used for a year and a half.
Jeff
-
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.
Are you running the new firmware? I had a problem with not recognizing a Kingston 4GB when running 1.2.3, then when I upgraded to 1.4.1b the card was recognized ok. If I switched back to the old firmware the MT would again not see the card correctly.
http://taperssection.com/index.php?topic=65514.0;all
-
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.
Are you running the new firmware? I had a problem with not recognizing a Kingston 4GB when running 1.2.3, then when I upgraded to 1.4.1b the card was recognized ok. If I switched back to the old firmware the MT would again not see the card correctly.
http://taperssection.com/index.php?topic=65514.0;all
Yeah I'm running the latest beta (1.4.1b9). No biggie was just testing to test. Thanks anyhow.
J.T.
-
Where is the bug submission form for M-Audio? This is actually in the 1.4.1b2 software but I bet this problem is still there. Basically this is what happens:
If you choose the 1/8" source input and then manually set the bits to 24 and frequency to 96 khz and then switch to SPDIF the microtrack does not auto detect the SPDIF frequency. Instead it uses what your previously selected frequency was. I noticed this problem at All Good as all my recordings from SPDIF had a 96khz freq even though I was running 44.1. Thus I had chipmunk syndrome. I then noticed that when I was messing around and switched it to 44.1, I was good to go, but I forgot and ran 24/48 at 10KLF which truncated some of my stuff from 48 to 44.1. Once I went and switched the frequency in the 1/8" mode to 48khz I was fine again.
So another day, another bug. At least this one has a work around.
-
Where is the bug submission form for M-Audio? This is actually in the 1.4.1b2 software but I bet this problem is still there. Basically this is what happens:
If you choose the 1/8" source input and then manually set the bits to 24 and frequency to 96 khz and then switch to SPDIF the microtrack does not auto detect the SPDIF frequency. Instead it uses what your previously selected frequency was. I noticed this problem at All Good as all my recordings from SPDIF had a 96khz freq even though I was running 44.1. Thus I had chipmunk syndrome. I then noticed that when I was messing around and switched it to 44.1, I was good to go, but I forgot and ran 24/48 at 10KLF which truncated some of my stuff from 48 to 44.1. Once I went and switched the frequency in the 1/8" mode to 48khz I was fine again.
So another day, another bug. At least this one has a work around.
Hmmm, I thought you were on to something but I just tried it out on 1.4.1b9 and I can't get it to happen. Care to try out b9 on your setup? The only time the chipmunks came to visit me was when I purposly connected the S/PDIF cable to the Microtrack AFTER starting the recording, I know no-no with this thing. It seems to me that the MicroTrack defualts to 96K if it doesn't have a signal at Rec time. Could be that it got fixed in b9 and they forgot to tell anyone.
J.T.
-
Where is the bug submission form for M-Audio? This is actually in the 1.4.1b2 software but I bet this problem is still there. Basically this is what happens:
If you choose the 1/8" source input and then manually set the bits to 24 and frequency to 96 khz and then switch to SPDIF the microtrack does not auto detect the SPDIF frequency. Instead it uses what your previously selected frequency was. I noticed this problem at All Good as all my recordings from SPDIF had a 96khz freq even though I was running 44.1. Thus I had chipmunk syndrome. I then noticed that when I was messing around and switched it to 44.1, I was good to go, but I forgot and ran 24/48 at 10KLF which truncated some of my stuff from 48 to 44.1. Once I went and switched the frequency in the 1/8" mode to 48khz I was fine again.
So another day, another bug. At least this one has a work around.
so if i have 1.4.0 i am ok?
-
Where is the bug submission form for M-Audio? This is actually in the 1.4.1b2 software but I bet this problem is still there. Basically this is what happens:
If you choose the 1/8" source input and then manually set the bits to 24 and frequency to 96 khz and then switch to SPDIF the microtrack does not auto detect the SPDIF frequency. Instead it uses what your previously selected frequency was. I noticed this problem at All Good as all my recordings from SPDIF had a 96khz freq even though I was running 44.1. Thus I had chipmunk syndrome. I then noticed that when I was messing around and switched it to 44.1, I was good to go, but I forgot and ran 24/48 at 10KLF which truncated some of my stuff from 48 to 44.1. Once I went and switched the frequency in the 1/8" mode to 48khz I was fine again.
So another day, another bug. At least this one has a work around.
Hmmm, I thought you were on to something but I just tried it out on 1.4.1b9 and I can't get it to happen. Care to try out b9 on your setup? The only time the chipmunks came to visit me was when I purposly connected the S/PDIF cable to the Microtrack AFTER starting the recording, I know no-no with this thing. It seems to me that the MicroTrack defualts to 96K if it doesn't have a signal at Rec time. Could be that it got fixed in b9 and they forgot to tell anyone.
J.T.
I'll test it out tonight.
-
FAT32 has a 4 GiB file size limit (2^32 = 4GB). Whatever they do, M-Audio would have to a have a pretty large buffer (let's say 24 bits x 96 ksps x 5 seconds to save/restart recording = 1440000 bytes = 1.37 MiB) to ever seamlessly exceed 4 GiB. I suspect that the buffer is already pretty large, and that a good portion of the "Writing file" save time is actually just flushing that buffer. Probably just not large enough for seamless splits. Or their programmers are lazy.
A workaround for FAT32 limitations would be to use a different filesystem, but a) they're probably using a 3rd party chip/driver to handle the flash card, so it'd take a lot of hackery to do that, and b) that would force us to use M-Audio's proprietary software to read the data on the flash card, which I think everyone would loathe.
The 2 GiB limit, if they really have decided not to fix in this hardware, is, if it's at all related to hardware, more likely a limitation of whatever chip they're using to interface with the flash card. Maybe it steals that last bit as a control or parity bit. Maybe some lazy engineer couldn't find the space for the last address line. Who knows. We're probably stuck with it. I record my stuff as MP3 anyway because my equipment/the recording environment is never going to be good enough for me to notice the difference between 24bit/96kHz and 320kbps/48kHz, so my biggest limitation is always that stupid permanent internal battery. And the flakey dollar store batteries I've been using to externally power the deal.