Taperssection.com
Gear / Technical Help => Recording Gear => Topic started by: eskin on May 04, 2006, 03:51:26 PM
-
New firmware up on the M-Audio site:
MicroTrack 24/96
Version: 1.4.0
Release Date: May 4, 2006
Applies to:
MicroTrack 24/96
Operating System(s):
Windows 2000, Windows XP
Release Notes:
This readme covers MicroTrack Firmware v1.4.0
============================================================
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, "PP5020.mi4", "BL_MPR.rom" and "Resources.arl," onto a properly formatted Compact Flash card in the root 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.0 and Bootloader 1.02
============================================================
Definitions: For the purposes of this document, the following definition applies:
‘Application’ refers to the user interface that allows for the playback and recording of audio. This is the mode in which the menus or the level and time indicators are on screen.
============================================================
Issues addressed by this release
-Sometimes wouldn’t use the entire available space of the media and would report media full before it actually was. Even after deleting previous recordings from the media.
-Sometimes reported incorrect file sizes on MP3s.
-Outputs would turn off during playback of some files.
-Autosplit feature would not always record to full 2GB file size when source is S/PDIF
-Files sometimes were not saved properly if the battery would run out during a recording.
-Sometimes would revert to default settings if the battery charge were to run out during use.
-Recordings would sometimes stop early (before filling media or reaching 2GB) when using S/PDIF as the source.
-Some French characters and translations were incorrect.
-Would not always display the full media message when it should.
-Could not play files from the ‘Files’ menu if the files were inside a folder.
-Sometimes would hang on writing very short (less than 1 second) recordings.
-Some S/PDIF recordings failed to start recording if they immediately followed an analog recording.
============================================================
User Interface change:
While charging with the unit in the Application, the battery icon will contain the letters CHG. This will remain until the battery voltage reaches 100% and remains there for one hour. At that time, the CHG will be replaced with a plug icon (indicating it is plugged in and supplying power but no longer charging the battery). This one hour ‘timer’ will be reset only if power is removed for longer than 3 minutes (which will prevent the unit from overcharging if the power is removed and returned for short periods of time).
-
Who's going to be the first to try it out? I'll wait 1-2 days before uploading it to my MT.
-
i just upgraded. will use it tommorrow night.
cross your fingers.
-
im gonna install it and do some testing at home tonight
-
I'm scared. Give it a try. I'll try later.
All the things I said were happening with 1.3.3, were addressed.
No seamless split, but we might be getting somewhere.
GO GO BETA TESTERS. >:D
report back ;)
-
i'm installing it and will use it in the field tomorrow. I'll let you know how it goes.
-
Thanks to the fearless testers! :clapping: :coolguy:
If anyone is running SPDIF in at 24 bit, can you check for channel flipping too? I wrote m-audio a few times about this but have never seen it mentioned as a fix.
-
oooh, i'll need to update before sts9 on saturday night. hopefully all will go well.
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
-
I'll be running it tomorrow ...
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
what size card?
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
When 1 kilobyte = 100 bytes and 1 Megabyte = 1000 kilobytes and 1 Gigabyte = 1000 Megabyte, 2 GB file will hold 2:53:37. That's based on 48000 sample rate, 16 bits, 2 channels.
Here's an old formula I have around for calculating space in an excel spreadsheet.
=2000/(((48000*16*2/8)/1000)*60/1000)/(360*4)
where 2000 is the file size (2 Gigabytes based on 1000's)
48000 is the sample rate (replace with whatever sample rate you want)
16 is the bit depth (replace with whateverbit depth you want, 16 or 24)
2 is the number of channels (2 for stereo, 1 for mono)
everything else give you the number in the proper form.
In general format, this will spit out the number as 0.12053272 and if you change the excel cell to time format (without am or pm) it will read 2:53:37
J.T.
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
When 1 kilobyte = 100 bytes and 1 Megabyte = 1000 kilobytes and 1 Gigabyte = 1000 Megabyte, 2 GB file will hold 2:53:37. That's based on 48000 sample rate, 16 bits, 2 channels.
Here's an old formula I have around for calculating space in an excel spreadsheet.
=2000/(((48000*16*2/8)/1000)*60/1000)/(360*4)
where 2000 is the file size (2 Gigabytes based on 1000's)
48000 is the sample rate (replace with whatever sample rate you want)
16 is the bit depth (replace with whateverbit depth you want, 16 or 24)
2 is the number of channels (2 for stereo, 1 for mono)
everything else give you the number in the proper form.
In general format, this will spit out the number as 0.12053272 and if you change the excel cell to time format (without am or pm) it will read 2:53:37
J.T.
That was excellent!!
+T ;D
-
ran 1.4 tonight. Did about a 90 minute file 16/44.1 using the 1/4 inputs. I was patching from the board at 9:30. Everything seemed ok. Playback didn't stop on the way home like usual.
I did have problems trying to listen through the headphones while recording. I turned it on in the record settings after I started recording and couldn't get anything to come out. I could see the levels moving and turned the volume all the way up. I was also running mics and plugged the headphones into my MD recorder and they worked fine there. Not sure what the issue was I'll play with it tomorrow. Do you have to set input monitoring to "ON" before you start recording?
-
ran 1.4 tonight. Did about a 90 minute file 16/44.1 using the 1/4 inputs. I was patching from the board at 9:30. Everything seemed ok. Playback didn't stop on the way home like usual.
I did have problems trying to listen through the headphones while recording. I turned it on in the record settings after I started recording and couldn't get anything to come out. I could see the levels moving and turned the volume all the way up. I was also running mics and plugged the headphones into my MD recorder and they worked fine there. Not sure what the issue was I'll play with it tomorrow. Do you have to set input monitoring to "ON" before you start recording?
Yep. Monitor "On"
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
If that's true then it is a joke!
How can a programmer use 1000*1000*1000 byte GB's instead of 1024*1024*1024!? ???
Is the software development outsourced as well?
I guess the hope for a seamless 2GB file switch (whatever 2GB it is..) can be abandoned?
I hope enough reports of this bug will come in. We need all of the real 2GB (the WAV format's limit) we can get. Not some stupid implementation that says less than 3 hours.
How can a non-US user make this clear to M-Audio without going through a local distributor?
-
ran 1.4 tonight. Did about a 90 minute file 16/44.1 using the 1/4 inputs. I was patching from the board at 9:30. Everything seemed ok. Playback didn't stop on the way home like usual.
I did have problems trying to listen through the headphones while recording. I turned it on in the record settings after I started recording and couldn't get anything to come out. I could see the levels moving and turned the volume all the way up. I was also running mics and plugged the headphones into my MD recorder and they worked fine there. Not sure what the issue was I'll play with it tomorrow. Do you have to set input monitoring to "ON" before you start recording?
Yep. Monitor "On"
Well I know it has to be "ON" :) but do you have to do it before you hit record, or can you change it once you have started recording? I'll play with it at home and find out.
-
Maybe my math is wrong - surely 44.1/16, but not 48/16 at 2GB should result in over 3 hrs?
Anyway, except for the auto-split issue, 1.4.0 is the first firmware that actually makes my MT useable for me. The Chinese OEM (whoever it is) should have instructed its marketing firm (M-Audio) to hold off on release until the basic bugs were ironed out. For example, what's up with the funky level meters during playback?! Back in the days before rabid globalization, these things simply could not have happened... You got to give the marketing firm credit, though - they got $400 out of me when it should have been $200 tops!
Cheers
PS Sorry to have to break it to you - it was the Chinese manufacturer that offshored/outsourced the marketing of their product to M-Audio. Who knows where the programming takes place. It's a brave new world we are living in. Crude engineering and tacked-on "Designed in USA" and "Engineered in USA" labels do not a US product make - but it still seems to fool quite a few (mostly younger) folks.
PPS I have to switch monitoring on before hitting "Rec." Then it works fine. Of course your MD would work fine, it's a properly engineered device. Sigh.
-
yeah, the mt pisses me off too, but its not like any of us were forced into buying it when we all knew that it had kinks to work out.
-
PPS I have to switch monitoring on before hitting "Rec." Then it works fine. Of course your MD would work fine, it's a properly engineered device. Sigh.
That's what I suspected. The odd thing is I know on 1.3.3(or whatever it was) I did turn input monitoring to "OFF" durring a recording and it stopped working. I can't remember if I turned it back on later in the set though. I don't usually use it but I was taking the board patch and just wanted to hear how it was coming through.
-
Glad to see people are having success. However, to be safe I think I am going to stick older firmware until some more try it. Is the new firmware still listed as beta?
Oh well... Using the old firmware for tool tonight.
-
Ran 1.4.0 24-48 SPDIF last night with no problems. second set went 1:54 with no shut downs or any other problems.
-
Ran Keller and the Keels last night. 24/48. Sets were 25:12, 65:32, 77:35, 34:00, 29:32
Ran mme > s/pdif
1.4 is a winner for me.
Has anyone tested the file splitting?
-
.
-
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
Did anyone report this bug to M-Audio?
-
Ran Keller and the Keels last night. 24/48. Sets were 25:12, 65:32, 77:35, 34:00, 29:32
Ran mme > s/pdif
1.4 is a winner for me.
Has anyone tested the file splitting?
I had held off from installing the 1.3.3 version on a hunch it was trouble, but had a 'good feeling' about 1.4.0 so installed it last night and let the deck run at 24 bit/88.2K with Sandisk Ultra II 8 GIG card with 1/4" analog input set at "L" line input using Sonic Studios external PA-24XP preamplifier. Deck was being powered by Sonic Studios BD-MT external D cell power sled, connected AFTER the deck booted up, but I don't know if connected before or after boot matters much.
Intended to let the card fill up and the deck make consecutive files which it did making (4) ~1:02:56 length files, and (1) ~00:02:56 short file without problem. Happened to check the progress just as the first file was reaching the 2 GIG limit and saw the deck close the first file, and start the second very quickly within ~3-4 seconds time.
To say the least, I am encourgaged so far. More testing of other aspects is in process. Other noticed improvements is the navagation toggle is VERY stable with EXACTLY one jump per activation verses the overshoot experienced with 1.2.3 (I do not know if this was already fixed in 1.3.3)
One possible 'hang-up' was after deleting a recorded file with the microtrack, the deck appears to freeze and not allow further recording, or I just got impatient waiting for some process to finish? The deck flashes deleting the file window briefly, and then returns to show the VU meter, but nothing else shows on the screen when pushing the REC button. Looking at the files with navagation showed the deleted files to be gone, but the deck refused to activate further recording of new files!
In any case, I found myself having to shut down the deck (removing external USB power included with this) and reboot to find the files still gone as they should, and the recording process now possible to activate.
Could be a bug, but more needs be tested more to see if this is a consistent problem, or just my very early morning imagination.
Other quirk was after making some initial short recordings, I reformatted the card to delete the files and start up fresh, which the deck did, and then got a message "the deck is now resetting" which makes the unit turn off completely. Manual reboot is needed after this, but everything seems to be working OK after that.
-
I installed v1.4.0 in the microtrack and just tested the audio playback function via the headphone jack. As noted by myself and other previously the Microtrack would stop output of the audio signal to the headphones after an undetermined period of time although the VU meters were still functioning correctly. This problem has apprently been fixed as I loaded a .wav file which I had previously made on the recorder to listen to. The file was a 24/44.1 file which was one hour nine minutes long and I was able to listen to it in its entirety without issues.
-
so far all the tests i have done (ua5>spdif>MT 24bit/44.1) with new firmware v1.4.0 have been successful except for one where i was using crappy batteries in a usb battery pack and they died. im keeping my fingers crossed though. its too soon to tell how reliable this is going to be.
with the v1.3.3 firmware 8 of 10 shows i taped were fucked up even though before that version of the firmware i was fine.
not counting the test where my battery ran out, i am 2 for 2 for flawless test recordings. in my house i recorded a 1 hour 20 min file, then a 2 hour file to simulate first set, then second set + encore. i formatted the card and tried it again and had no problems in either test.
im going to try it a few more times today, then tape a tim palmieri solo acoustic show tomorrow. if i get through the tests and the show tomorrow i will be more confident that this thing will be reliable from this point on.
1 question i have for you guys with microtracks:
I was having problems with the channel swapping thing in all versions of the firmware before 1.4.0. i forgot to check before formatting my card after the tests i just did, but the channels were not swapped while i was monitoring the level meters. could you tell the channels were swapped while monitoring in older versions, or did you have to actuallly open the file on the pc to find out whether or not the channels got swapped?
-
Well, here are my findings from 1.4.0...
I went to STS9 last night, IsWhat was the opener...I decided to try out my new compact flash card for this...it is the off brand one found in the retail section that was less than $100. (http://taperssection.com/index.php?topic=62324.0) Its probably important to not that I was running spdif in from the v3, taping at 24/48. When I first hit record I got the message "Media Full" - there was nothing on the card and I thought that I had formatted it at home before I left. I formatted it again, hit record and everything seemed to work like normal. At 3:30 it quit writing the file and started a new one. I should add that I was holding the mt at this point in time checking to make sure that it was going ok, so its possible that the spdif cable might have jiggled or I did something to cause it to start a new file. Upon listening theres about a 1/10 of a second of static at the beginning of the file and then it continues as normal. The rest of the recording is flawless. So I'm guessing it was me that messed up the first file.
For STS9 I ran the 6gb Hitachi Microdrive. No problems running at 24/48 and from what I could tell, all was as it should be. All the numbers and countdown timers were correct from what I could tell. The recordings are flawless...and sound damn nice too. Also, I listened to the recordings on my way home, playing from the MT and they never cut out like they used to. I did notice at about 28 minutes in the recording stopped for a second and then started back up where it left off. I'm guessing this was just the mt resetting its buffer or something. Not a big deal by any means and much better than before. I listened to that spot when I got home and the recording itself doesn't skip on my computer, so all is well.
So far, so good. The battery still sucks though.
-
I suppose that the battery "sucks" (no pun intended) if you are powering the microphones from the MT. I am supplying power to my DPA 4061's via an external a/d converter mic preamplifier and typically get on the order of four and a half to five hours of battery run time even with the backlight set to always on. Once I start my rig up I immediately select the "hold" button and then adjust my gain settings from the a/d converter mic preamplifier. I have fortunately not experienced the problems with my microtrack that most of you have had. I am going in spdif and have made several 24/96 recordings since 1.33 was released all with excellent results.
I hope that the current release is even more robust for the rest of the microtrack community as it is a great piece to strealth with. Using good quality microphones and an external a/d converter the results are as good as any of the more expensive recorders for a fraction of the price. As long as you are able to work around the file split issue for now in my opinion nothing can touch this piece. I simply make a new file when the band members are introduced and then I am good to go for the rest of the night. Most concerts I attend are approximately 90 minutes to just under two hours so It is perfect for 24/96 on a 4 GB card. Two files with a small amount of room to spare!
-
I guess I'll be trying this out tonight, hope all goes well (although honestly i haven't had any significant issues so far...).
But this does remind me... does anyone know if there are any plans to re-work the battery indicator to "make some sense"? I absolutely hate the diagonal line readout for how much battery life is left and wish they'd change it to just a solid bar like every other professional and semi-pro audio/video gear I've ever used.
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
If that's true then it is a joke!
How can a programmer use 1000*1000*1000 byte GB's instead of 1024*1024*1024!? ???
Is the software development outsourced as well?
I guess the hope for a seamless 2GB file switch (whatever 2GB it is..) can be abandoned?
I hope enough reports of this bug will come in. We need all of the real 2GB (the WAV format's limit) we can get. Not some stupid implementation that says less than 3 hours.
How can a non-US user make this clear to M-Audio without going through a local distributor?
It's true but is an extra 8 minutes and 26 seconds really that big a deal? Sure I'd like the 'extra' time too since it should be possible but I'm just happy that there were a bunch of bugs fixed.
For those that care, I cruched the numbers and here are the wav file record time for every bit depth, sample rate and mono and stereo configuraiton. Along with how much more time we'd get if it used 1024 as the basis for it's calculations.
1000 1024 difference
44100 / 16 / mono 6:17:56 6:36:17 0:18:21
44100 / 24 / mono 4:11:57 4:24:11 0:12:14
48000 / 16 / mono 5:47:13 6:04:05 0:16:52
48000 / 24 / mono 3:51:29 4:02:44 0:11:15
82000 / 16 / mono 3:08:58 3:18:09 0:09:11
82000 / 24 / mono 2:05:59 2:12:06 0:06:07
96000 / 16 / mono 2:53:37 3:02:03 0:08:26
96000 / 24 / mono 1:55:44 2:01:22 0:05:37
44100 / 16 / stereo 3:08:58 3:18:09 0:09:11
44100 / 24 / stereo 2:05:59 2:12:06 0:06:07
48000 / 16 / stereo 2:53:37 3:02:03 0:08:26
48000 / 24 / stereo 1:55:44 2:01:22 0:05:37
82000 / 16 / stereo 1:34:29 1:39:04 0:04:35
82000 / 24 / stereo 1:02:59 1:06:03 0:03:04
96000 / 16 / stereo 1:26:48 1:31:01 0:04:13
96000 / 24 / stereo 0:57:52 1:00:41 0:02:49
It's a difference of 4.85% more recording time per file. Again sure I wish I had it too just in case but I'm not overly bummed about it.
J.T.
-
I was having problems with the channel swapping thing in all versions of the firmware before 1.4.0. i forgot to check before formatting my card after the tests i just did, but the channels were not swapped while i was monitoring the level meters. could you tell the channels were swapped while monitoring in older versions, or did you have to actuallly open the file on the pc to find out whether or not the channels got swapped?
I toggle the 48V phantom on the left channel off and back on while recording either before or after the set, you can see on the level meters on the MT if the correct channel is responding.
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
If that's true then it is a joke!
How can a programmer use 1000*1000*1000 byte GB's instead of 1024*1024*1024!? ???
Is the software development outsourced as well?
I guess the hope for a seamless 2GB file switch (whatever 2GB it is..) can be abandoned?
I hope enough reports of this bug will come in. We need all of the real 2GB (the WAV format's limit) we can get. Not some stupid implementation that says less than 3 hours.
How can a non-US user make this clear to M-Audio without going through a local distributor?
It's true but is an extra 8 minutes and 26 seconds really that big a deal?
8 min 26?
Rather 13 minutes.
Sure I'd like the 'extra' time too since it should be possible but I'm just happy that there were a bunch of bugs fixed.
This is a bug that is easily fixed.
48000 / 16 / stereo 2:53:37 3:02:03 0:08:26
I get to 3h06 for 48/16: 2*1024*1024*1024/(48000*2*2*3600) hours
Based on that it is 13 minutes or so.
That is 7.7+%
Somethign to be bummed about because I hate breaks in my audio.
There is no seamless autosplit and now this bug...
-
(2*1024*1024*1024)/2000000000 gives the same 1.07...
-
I suppose that the battery "sucks" (no pun intended) if you are powering the microphones from the MT.
The neumanns get powered by the v3, in fact, i haven't even used the analog ins on mt. I also hook up a usb batt box to the MT and by the end of the night, the battery is still over half way depleted. And thats at shutting it off between bands and setbreaks.
-
Installed it, will use it tonight.
At 48/16, it reports max time per file as 2:53:36!? (should be over 3 hours!) ???
That's the time you get when you base your calculations on kilobytes, megabytes and Gigabytes all being 1000 instead of 1024 so that must be what's happening.
If that's true then it is a joke!
How can a programmer use 1000*1000*1000 byte GB's instead of 1024*1024*1024!? ???
Is the software development outsourced as well?
I guess the hope for a seamless 2GB file switch (whatever 2GB it is..) can be abandoned?
I hope enough reports of this bug will come in. We need all of the real 2GB (the WAV format's limit) we can get. Not some stupid implementation that says less than 3 hours.
How can a non-US user make this clear to M-Audio without going through a local distributor?
It's true but is an extra 8 minutes and 26 seconds really that big a deal?
8 min 26?
Rather 13 minutes.
Sure I'd like the 'extra' time too since it should be possible but I'm just happy that there were a bunch of bugs fixed.
This is a bug that is easily fixed.
48000 / 16 / stereo 2:53:37 3:02:03 0:08:26
I get to 3h06 for 48/16: 2*1024*1024*1024/(48000*2*2*3600) hours
Based on that it is 13 minutes or so.
That is 7.7+%
Somethign to be bummed about because I hate breaks in my audio.
There is no seamless autosplit and now this bug...
deep ass quote, anyway..
It really could be that they use some of the extra space for buffering and that sort...
-
8 min 26?
Rather 13 minutes.
Yep sorry about that. I was wrong, or at least my math was. Although I had switched to 1024 units I had forgotten to take into account that in addition to using a different calcuation, it would also keep going after reaching 2000 going to 2048 Megabte instead. My bad. It still doesn't bother me but yes I'd think they could fix it if they are made aware of it loudly enough. ^-^
I would also assume, as someone else suggested, that they probably leave a bit of extra room as a 'safety' net but they shouldn't need that much.
Again, sorry about my screwed up math.
J.T.
-
8 min 26?
Rather 13 minutes.
Yep sorry about that. I was wrong, or at least my math was.
No problem. I got an email from M-Audio, so at least someone is aware of this 2GB issue. They are looking at fixing it in a future firmware release. (of course vague as can be...)
-
8 min 26?
Rather 13 minutes.
Yep sorry about that. I was wrong, or at least my math was.
No problem. I got an email from M-Audio, so at least someone is aware of this 2GB issue. They are looking at fixing it in a future firmware release. (of course vague as can be...)
No sane programmer would use 1000 in stead of 1024. However, sales-people would. In the hard-disk and 'media'-storage world, disks and cards are often labeled with 'GB' which are actually 1000*1000*1000 bytes. This means slightly less bytes on a disk, so a physically slightly smaller hard disk (or less dense 'plate'), so less costs for the manufacturer.
I assumed the MT firmware programmers simplly used '1000' to stay closer to what the your media actually is, in stead of how it's been labelled.
So either:
1. The MT uses '1000': customers complain to M-Audio that the files could be bigger, hence recordings could be a bit longer before it hits the maximum of 2GB.
2. The MT uses '1024': customers complain to M-Audio that their '4GB' card can't hold two 2GB files. (or ideally they complain to the card-manufacturer)
Roel
-
So either:
1. The MT uses '1000': customers complain to M-Audio that the files could be bigger, hence recordings could be a bit longer before it hits the maximum of 2GB.
2. The MT uses '1024': customers complain to M-Audio that their '4GB' card can't hold two 2GB files. (or ideally they complain to the card-manufacturer)
Roel
Good point. I'm also worried that if they fill up the media too full, ithe bug where it was sometimes failing to properly save the files when the media was full will come back. I'll gladly take a 15 minutes shorter record time over risking losing my entire recording session. But hopefully they'll be careful about 'fixing' this one when and if they get around to it. With so many fixes in this one and the length of time it took to come out, I kind of get the feeling that this may have been kind of a 'wrap up' release and we might not see another for awhile barring something catastrophic, but that's just my gut, it's been wrong before.
BTW, I went back out of curiosity to the first firmware and it looks like this bug has been there all along.
J.T.
-
Was just trying to "bit bucket" a DAT from 2001, when he deck refused to start when the DAT started.
Any way, all of a sudden, the back-light was staying on and none of the buttons work. The HOLD is not on, and the unit is locked up.
How can I get out of this? Is there a key press combo or something to force a reboot/cold start?
Using 1.4.0... thanks, Greg
-
Was just trying to "bit bucket" a DAT from 2001, when he deck refused to start when the DAT started.
Any way, all of a sudden, the back-light was staying on and none of the buttons work. The HOLD is not on, and the unit is locked up.
How can I get out of this? Is there a key press combo or something to force a reboot/cold start?
Using 1.4.0... thanks, Greg
Digi connection?
Make sure it is active (with signal) before starting the MT.
Hold down the power button a few seconds to power down.
-
Dig connection?
Make sure it is active (with signal) before starting the MT.
Hold down the power button a few seconds to power down.
Yes, DIG connection
Signal, as in source device on? or on and sending audio?
Power button (and all of them) did nothing, had to wait for the battery to die and then plug in power again.
-
Dig connection?
Make sure it is active (with signal) before starting the MT.
Hold down the power button a few seconds to power down.
Yes, DIG connection
Signal, as in source device on? or on and sending audio?
Power button (and all of them) did nothing, had to wait for the battery to die and then plug in power again.
You have to hold the power button down for about 12 seconds continuously or longer to get it to force power off. This has always worked for me when I eneded up with a frozon unit for any reason.
-
Signal, as in source device on? or on and sending audio?
Sending signal I guess. (I do not use SPDIF)
-
I just wish they could get enough units out to supply the European market.
To quote M Audio directly form a recent E-Mail I recieved 25.04.06:
"Just to advise you it is not a production problem but a 'high demand issue'. We had stock arrive at the beginning of April and we actually sold over 1500 units in 2 weeks. Normally this is a months supply. We did not foresee the growth in the market for this item.
We are currently out of stock but will have a large shipment in Europe middle of next month. We will fulfil all the orders when they arrive.
We would like to thank you for your support in our products and apologise for the delay in you recieving this item.
We will be trying to produce more in future so we can fulfil the demand."
Ho hum suppose they could be ironing out "bugs"
-
Was just trying to "bit bucket" a DAT from 2001, when he deck refused to start when the DAT started.
Any way, all of a sudden, the back-light was staying on and none of the buttons work. The HOLD is not on, and the unit is locked up.
How can I get out of this? Is there a key press combo or something to force a reboot/cold start?
Using 1.4.0... thanks, Greg
this sort of happened to me on monday
I was running 16/44.1 spdif fw 1.1.5
the mt light stayed on, and none of the buttons worked, I was glad I ran a dat back up. I just let the mt sit over night to power down. I then repowered it and checked the files. All seem to be there, although I havnt actually listened to them yet!
-
My gosh, it's been two whole days without any additions to the thread... are we approaching stability?!
I've had no problems with 1.3.3, but upgraded anyway. I don't go digi-in, as that seemed to cause many of the issues. Now if they could somehow implement a seemless split, we be golden. I doubt that will happen, as it would require a record buffer similar the the 7xx series.
Great job by all the users in reporting the bugs and getting to this point!
Scott
-
Upgraded to 1.4, ran for two sets last night, each 1hr. SPDIF in, 24/48. No probs at all.
-
My gosh, it's been two whole days without any additions to the thread... are we approaching stability?!
I was just thinking the same thing. I'm taping Sunday night and it will be the first time out since 1.4.0 appeared. I'm not hearing any reason at this point not to give it a shot. Heck, now that I've got a 4GB microdrive maybe I'll even go 24/48.
-
My gosh, it's been two whole days without any additions to the thread... are we approaching stability?!
I was just thinking the same thing. I'm taping Sunday night and it will be the first time out since 1.4.0 appeared. I'm not hearing any reason at this point not to give it a shot. Heck, now that I've got a 4GB microdrive maybe I'll even go 24/48.
There's still the 2.000.000.000 byte restriction and no seamless splits, so plan in advance.
-
I figured out the problem. this mt, and I guess all harddrivish recorders, really dont like it when you cut the signal, and its still recording, not like dat that would still give you the recorded material.
Was just trying to "bit bucket" a DAT from 2001, when he deck refused to start when the DAT started.
Any way, all of a sudden, the back-light was staying on and none of the buttons work. The HOLD is not on, and the unit is locked up.
How can I get out of this? Is there a key press combo or something to force a reboot/cold start?
Using 1.4.0... thanks, Greg
this sort of happened to me on monday
I was running 16/44.1 spdif fw 1.1.5
the mt light stayed on, and none of the buttons worked, I was glad I ran a dat back up. I just let the mt sit over night to power down. I then repowered it and checked the files. All seem to be there, although I havnt actually listened to them yet!
-
So far so good. Had my first trouble-free recording using digi-in (24/44.1) with the Microtrack running 1.4.0 earlier tonight. Recorded Willy Porter for a little over an hour, then Glen Phillips for about 98 minutes on the same 4Gb CF card. No unexpected stoppages, and the MT also did not explode!
-
My gosh, it's been two whole days without any additions to the thread... are we approaching stability?!
Not so fast...
I was all set to come in and say mine is continuing to work perfectly, because up to now I've not had a problem with any of the firmwares, and my MT has been 100% reliable... but I got bitten a couple of days ago.
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.
I created a missing file on another card to see if anything was actually recorded and is recoverable with scandisk or something, but no luck yet...
-
So now I have a CF card that may or may not have the second encore of Radiohead 2nd night in Blackpool hiding on it. I created a missing file on another card to see if anything was actually recorded and is recoverable with scandisk or something, but no luck yet...
Wow.. That's a serious new bug. Thanks for mentioning it. It would be easy to take the entire image of the cf card under linux to play with/send to others but I'm not sure how to do it under windows/mac. I think it is probably on there..
-
Can I suggest or even request, if you're not already doing it, that you (or anyone else who might be able to help) create a missing file, and see if you can find it hiding on the card?
I've downloaded some file recovery tools including one mentioned here in another thread. None of them have found the missing file yet. The free space on the card both in Windows and on the MT time remaining are consistent with data not having been writen...
-
Good catch (+t) - that's a dealbreaker for me... goodbye to 1.4.0, back to 1.3.3.
Scott
-
So now I have a CF card that may or may not have the second encore of Radiohead 2nd night in Blackpool hiding on it. I created a missing file on another card to see if anything was actually recorded and is recoverable with scandisk or something, but no luck yet...
Wow.. That's a serious new bug. Thanks for mentioning it. It would be easy to take the entire image of the cf card under linux to play with/send to others but I'm not sure how to do it under windows/mac. I think it is probably on there..
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
-
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)
-
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.
-
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)
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
Thanks for the testing, kids. I am staying with 1.2.3.
It works fine.
-
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.
-
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?
-
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.
-
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...
-
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.
-
I guess I'm going to stay with the 1.3.3 from what I've been reading here.
-
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.
But why would it 'have' to be writing to the card - it might've been in some sort of record-pause mode - since file recovery programs on my computer at home didn't appear to be able to find any lost data or files, it wasn't clear if anything had actually been written.
But to answer my own question, I tried the card in my fairly new WinXP computer at work, and wahey - R-Studio found the missing file and was able to recover it with the correct filename and all. So with the costs of getting to the gig, and then buying file recovery software, not the cheapest recording I've ever made.
And the other night when I had the same situation again with manual file split, waiting 'til the first file had finished writing before the second button press meant it worked perfectly, albeit with the process now taking a couple of seconds longer, so I'm back to being happy with my MT at least.
-
I guess I'm going to stay with the 1.3.3 from what I've been reading here.
Why?
What is wrong?
I've been using 1.4.0 since it came out and yes, it has bugs.
Those are known now.
But 1.4.0 is still an improvement. Or isn't it?
Please comment.
-
I guess I'm going to stay with the 1.3.3 from what I've been reading here.
Why?
What is wrong?
I've been using 1.4.0 since it came out and yes, it has bugs.
Those are known now.
But 1.4.0 is still an improvement. Or isn't it?
Please comment.
I'm with you on this one, 1.4.0 is the most reliable firmware I have used thus far.
-
I guess I'm going to stay with the 1.3.3 from what I've been reading here.
Why?
What is wrong?
I've been using 1.4.0 since it came out and yes, it has bugs.
Those are known now.
But 1.4.0 is still an improvement. Or isn't it?
Please comment.
I'm with you on this one, 1.4.0 is the most reliable firmware I have used thus far.
I don't know. After many problems with 1.3.3, I went back to 1.2.3. Not one problem since then. I have to auto-split with my finger, but I always did that anyway. I'm not going to have a split in the middle of the song.
I did have a problem with my JB3, though. I ran out of space. ::) Sad when you have a 40 gig jb3. It was just a backup luckily.
-
I guess I'm going to stay with the 1.3.3 from what I've been reading here.
Me too.
-
(please mention the 2GB bugs as well: 2.000.000.000 versus real 2GB and seamless autosplit)
As previously mentioned, this is not a "bug" but the marketing standard for all storage devices.
I would be completely shocked if any other recorder actually uses 1024 as the factor and not 1000. As previously mentioned, this goes against the advertised capacity of all hard drives, RAM, CF, etc.!
While I don't disagree that it is at it's root misleading, it's just one of those things you have to grin and accept now, because there's no chance of it changing.
-
(please mention the 2GB bugs as well: 2.000.000.000 versus real 2GB and seamless autosplit)
As previously mentioned, this is not a "bug" but the marketing standard for all storage devices.
I would be completely shocked if any other recorder actually uses 1024 as the factor and not 1000. As previously mentioned, this goes against the advertised capacity of all hard drives, RAM, CF, etc.!
While I don't disagree that it is at it's root misleading, it's just one of those things you have to grin and accept now, because there's no chance of it changing.
The WAV format allows for 2 real GB's.
So why not use the recording space we can get while there is no autosplit?
In computerland (i.e.: at least software) Kilo is 1024. Not 1000. Whatever the marketing thinks they can get away with is their fault.
-
(please mention the 2GB bugs as well: 2.000.000.000 versus real 2GB and seamless autosplit)
As previously mentioned, this is not a "bug" but the marketing standard for all storage devices.
I would be completely shocked if any other recorder actually uses 1024 as the factor and not 1000. As previously mentioned, this goes against the advertised capacity of all hard drives, RAM, CF, etc.!
While I don't disagree that it is at it's root misleading, it's just one of those things you have to grin and accept now, because there's no chance of it changing.
The WAV format allows for 2 real GB's.
So why not use the recording space we can get while there is no autosplit?
In computerland (i.e.: at least software) Kilo is 1024. Not 1000. Whatever the marketing thinks they can get away with is their fault.
WAV may allow for REAL 2GB, but will this fit on a "2GB" card? No. Two 2GB files will not fit on a 4GB card either.
My "120GB HD" I bought a few years ago actually had something like 113 GB because of it. Misleading? Yes, but I knew it ahead of time, it's how HD's have worked for as long as I have used computers.
I think it's the stupidest marketing I've ever heard of, because it actually makes computing more difficult (unlike the mhz war which just confused grandma). But you know the cliche...change what you can, accept what you can't!
-
WAV may allow for REAL 2GB, but will this fit on a "2GB" card? No. Two 2GB files will not fit on a 4GB card either.
Get a 4GB card.
Record for over 3 hours without breaks.
-
(please mention the 2GB bugs as well: 2.000.000.000 versus real 2GB and seamless autosplit)
As previously mentioned, this is not a "bug" but the marketing standard for all storage devices.
I would be completely shocked if any other recorder actually uses 1024 as the factor and not 1000. As previously mentioned, this goes against the advertised capacity of all hard drives, RAM, CF, etc.!
While I don't disagree that it is at it's root misleading, it's just one of those things you have to grin and accept now, because there's no chance of it changing.
No chance of changing it?!? Not with that negative ass attitude! ^-^
I had entered a support ticket for this max file size issue since I record at 24/48 and their 1000 byte calculation is robbing me of almost 10 minutes record time in a file. That could be the difference of a gap in the middle of a song or capturing the entire show uncut!
After going back and forth with the support tech (and him wanting me to defragment my CF card ::) ), he updated the ticket today saying the developers were aware of the issue and were working on a resolution.
Later,
pjdavep
-
I would like to say that I have been running this spdif 2Gb 24/48 for almost 2 months, rock solid.
It's good folks.
-
This thread sure got quiet.... so quick question.
How do you enable the "auto file split" that was put in on this release, or is it automatic (even if you loose 5-10 seconds of record time)?
Thanks
-
automatic
-
is there a link for 1.4.0?
i cant seem to ever find the update via M-Audio's website...looking to update from 1.2.3
or, from what i have been reading, should i dare update??
-
http://m-audio.com/index.php?do=support.drivers&k=firmware&b=1 (http://m-audio.com/index.php?do=support.drivers&k=firmware&b=1)
Choose USB Audio Series and then pick yer OS.
-
thats what was wrong...i still had driver updates selected, not firmware!
+T MWZ
so, whats the consensus on the 1.2.3 upgrade?
-
I haven't had any problems with 1.4.0 other than my own user error. (plug the coax cable in all the way).
Its been pretty rock solid in what it does as a bit bucket and this firmware handles microdrives the best.
-
This thread sure got quiet.... so quick question.
How do you enable the "auto file split" that was put in on this release, or is it automatic (even if you loose 5-10 seconds of record time)?
Isn't that an automagic feature?
-
well, i tried out the new firmware update last nite without pretesting after the install.
WSP @ red rocks, so i knew it would be a solid test run
NO PROBLEMS....ran 24/48 SPDIF from the V3 and so far nothing bad to report.
first set 1:05 using the Hitachi 4GB microdrive (it did get hot as hell in my bag, but it could have been b/c the top was closed)
2nd set: 1:48 + manual split during encore break using the 45x Kingston 4GB compact flash
looking forward to the rest of the weekend.
now if they can get the 2GB autosplit with no gap ,i will be a happy camper
-
is there a link for 1.4.0?
i cant seem to ever find the update via M-Audio's website...looking to update from 1.2.3
or, from what i have been reading, should i dare update??
This is not the newest firmware (1.4.0). There have been 2 updates since, both fixing specific hiccups from this version. I upgraded even though the fixes were not important to me (you never know). I have run the unit three times since and the latest version, Microtrack 1.4.1b2
appears to also be rock solid. That is the thread that should be in use. It is time to put this thread to sleep.
I have not had any issues with my MT since 1.4.0 or earlier. Perhaps the MT was released before it was ready, but I have no regrets at all. The unit is fully reliable to me, so much so that my jb3 has gone from main, to backup, to in the drawer. ;D Life is good...
-
It is time to put this thread to sleep.
I agree! It's putting me to sleep. :zzz:
I'm with Cliff. MT is rock solid. Ran it for 3 full sets last night plus a quick restart after the band was coerced into one more song. I run it 16/44.1 and 24/48. Damn 24 bit sounds great, now I need to get a new squeeze box so I can actually listen to 24 bit.
-
its a shame tho, if they got the 2-GB thing fixed, this lil box would be PERFECT, hell, id buy one just to stealth with ;)
-
well, i tried out the new firmware update last nite without pretesting after the install.
WSP @ red rocks, so i knew it would be a solid test run
NO PROBLEMS....ran 24/48 SPDIF from the V3 and so far nothing bad to report.
first set 1:05 using the Hitachi 4GB microdrive (it did get hot as hell in my bag, but it could have been b/c the top was closed)
2nd set: 1:48 + manual split during encore break using the 45x Kingston 4GB compact flash
looking forward to the rest of the weekend.
now if they can get the 2GB autosplit with no gap ,i will be a happy camper
no major problems again last nite.
the onyl weird thing that happened was after 1:35 of recording i did the manual split prior to the encore, but it seemed like it froze during the file save...i let it go for 30seconds which is ample time to finish saving before reseting via power button.
the complete file was there when i got home tho, so thats all that matters!
-
no major problems again last nite.
the onyl weird thing that happened was after 1:35 of recording i did the manual split prior to the encore, but it seemed like it froze during the file save...i let it go for 30seconds which is ample time to finish saving before reseting via power button.
the complete file was there when i got home tho, so thats all that matters!
I'd call that a major problem.. Surely not something you want to have happen at a tool show or in the front row of some spectacular jazz show. Someone said the mt is 'rock solid'.. If the mt is 'rock solid', what do you call the jb3, R-1 or 722 reliability? The mt still isn't at the reliability of the jb3 or, it seems, the R-1 and countless other devices.
With the jb3 or 722, I just take it for granted that the recorder will be completely predictable, reliable and drama-free. I'm not talking over a few shows. Record a hundred shows with a jb3, mt and a 722.. How many seconds of the performances (from first applause to last) do you miss and with how much 'OMFG, why won't it save and restart!?' type drama. I hate that kind of drama!
With new folks still coming in and wondering about the mt, I don't think it is accurate or fair to say it is 'rock solid' ;)
-
no major problems again last nite.
the onyl weird thing that happened was after 1:35 of recording i did the manual split prior to the encore, but it seemed like it froze during the file save...i let it go for 30seconds which is ample time to finish saving before reseting via power button.
the complete file was there when i got home tho, so thats all that matters!
I'd call that a major problem.. Surely not something you want to have happen at a tool show or in the front row of some spectacular jazz show. Someone said the mt is 'rock solid'.. If the mt is 'rock solid', what do you call the jb3, R-1 or 722 reliability? The mt still isn't at the reliability of the jb3 or, it seems, the R-1 and countless other devices.
With the jb3 or 722, I just take it for granted that the recorder will be completely predictable, reliable and drama-free. I'm not talking over a few shows. Record a hundred shows with a jb3, mt and a 722.. How many seconds of the performances (from first applause to last) do you miss and with how much 'OMFG, why won't it save and restart!?' type drama. I hate that kind of drama!
With new folks still coming in and wondering about the mt, I don't think it is accurate or fair to say it is 'rock solid' ;)
This was a known flaw in 1.4.0 that the next version 1.4.1 B1 quickly discovered and fixed. The best version to run is the newest version, (Microtrack 1.4.1b2) not 1.4.0.
My jb3 is in the drawer and there it will stay until I have time to put it in the yard sale. :)
I fairness to all the mis-information out there, I'll amend. My MT is rock solid. :angel:
-
until the 2gb thing is fixed, this thing is useless IMO for 24-bit recording :) but if ya'll can get under the 2gb thing, its a cheap 24-bit recorder
-
With the jb3 or 722, I just take it for granted that the recorder will be completely predictable, reliable and drama-free. I'm not talking over a few shows. Record a hundred shows with a jb3, mt and a 722.. How many seconds of the performances (from first applause to last) do you miss and with how much 'OMFG, why won't it save and restart!?' type drama. I hate that kind of drama!
See this thread on my R1 problems: http://taperssection.com/index.php?topic=61949.0
I know of several people who have had some 722 issues... so nothing is perfect!
-
This was a known flaw in 1.4.0 that the next version 1.4.1 B1 quickly discovered and fixed. The best version to run is the newest version, (Microtrack 1.4.1b2) not 1.4.0.
I just checked m-audio.com and it only shows 1.4.0... how/where can i find the "b2" version?
TIA
-
This was a known flaw in 1.4.0 that the next version 1.4.1 B1 quickly discovered and fixed. The best version to run is the newest version, (Microtrack 1.4.1b2) not 1.4.0.
I just checked m-audio.com and it only shows 1.4.0... how/where can i find the "b2" version?
TIA
make sure to select include beta versions
-
make sure to select include beta versions
dolt
-
By all indications, your R1 was defective. So I don't see how that applies.
As far as suggesting via third party account that the 722 has "issues"... Can you name one?
Yes it was defective, but it just stopped working correctly, during a show, so there should always be that fear of others having similar issues.
A DMB taper (I would have to check and see who, as I do not recall off hand) had problems with his over heating and had to send it back for repairs (or replacement, it was last summer so I have lost track). Not to mention lots of people who have their units get so hot (from the hard drive heat) that they almost burn body parts.
I love my R1 and the 722 (I have unlimited access to one) and am no way knocking them down, but new users should be made aware.
-
Not to mention lots of people who have their units get so hot (from the hard drive heat) that they almost burn body parts.
"almost burn" is kinda like "almost got run over by a garbage truck". Either you did or you didn't.
The 722 does get warm and can get hot.. But we simply don't see any reports of 'my 722 died' here. Or people getting burned by them.. Even people who have run them against their bodies for many many shows.
When I say 'issues', I'm talking lost recordings and major incidents that threaten recordings during shows. Not 'it feels hot'....
-
This was a known flaw in 1.4.0 that the next version 1.4.1 B1 quickly discovered and fixed. The best version to run is the newest version, (Microtrack 1.4.1b2) not 1.4.0.
I just checked m-audio.com and it only shows 1.4.0... how/where can i find the "b2" version?
TIA
make sure to select include beta versions
http://www.m-audio.com/index.php?do=support.drivers&k=firmware&b=1&s=6&p=196cc4c35a380d800a80448f139bcfe7&o=15&f=734
-
well, i tried out the new firmware update last nite without pretesting after the install.
WSP @ red rocks, so i knew it would be a solid test run
NO PROBLEMS....ran 24/48 SPDIF from the V3 and so far nothing bad to report.
first set 1:05 using the Hitachi 4GB microdrive (it did get hot as hell in my bag, but it could have been b/c the top was closed)
2nd set: 1:48 + manual split during encore break using the 45x Kingston 4GB compact flash
looking forward to the rest of the weekend.
now if they can get the 2GB autosplit with no gap ,i will be a happy camper
no major problems again last nite.
the onyl weird thing that happened was after 1:35 of recording i did the manual split prior to the encore, but it seemed like it froze during the file save...i let it go for 30seconds which is ample time to finish saving before reseting via power button.
the complete file was there when i got home tho, so thats all that matters!
i suppose i'll have to check out the new beta firmware
3rd nite WSP using 1.4.0: NO PROBLEMS @ 24/48
-
I never noticed this before. I bought a second 2 gig card (39.) so I could record SCI at 24 bits... During intermition I made a big deal of needing to do a "tape flip"... (cute). anyway I found a "bug". When you power down and then change cards and reboot... you might get a "no media found" or you go into "files" and it shows nothing... power down, reboot and then its fine. It happens over and over. Maybe somthing to be addressed or at least something to remember if your in a panic card flip hurry.
-
I never noticed this before. I bought a second 2 gig card (39.) so I could record SCI at 24 bits... During intermition I made a big deal of needing to do a "tape flip"... (cute). anyway I found a "bug". When you power down and then change cards and reboot... you might get a "no media found" or you go into "files" and it shows nothing... power down, reboot and then its fine. It happens over and over. Maybe somthing to be addressed or at least something to remember if your in a panic card flip hurry.
Did you have external battery/power attached? I only get this if I have my external battery attached. I can not remove the media if any form of external power is attached. I have to shut down, remove power connection then I can remove media. Once the new media is in, I can replace the external power and reboot to begin recording with the new media.
-
I never noticed this before. I bought a second 2 gig card (39.) so I could record SCI at 24 bits... During intermition I made a big deal of needing to do a "tape flip"... (cute). anyway I found a "bug". When you power down and then change cards and reboot... you might get a "no media found" or you go into "files" and it shows nothing... power down, reboot and then its fine. It happens over and over. Maybe somthing to be addressed or at least something to remember if your in a panic card flip hurry.
Did you have external battery/power attached? I only get this if I have my external battery attached. I can not remove the media if any form of external power is attached. I have to shut down, remove power connection then I can remove media. Once the new media is in, I can replace the external power and reboot to begin recording with the new media.
Most definently true. Always disconnect your external power before shutting down the box as it will just try to turn right back on with the USB power.
-
yep, had a few screw-ups of the my own that were caused by not removing the batt power before restarting >:(
-
Dumb question but was the card formatted?
-
It's true but is an extra 8 minutes and 26 seconds really that big a deal? Sure I'd like the 'extra' time too since it should be possible but I'm just happy that there were a bunch of bugs fixed.
For those that care, I cruched the numbers and here are the wav file record time for every bit depth, sample rate and mono and stereo configuraiton. Along with how much more time we'd get if it used 1024 as the basis for it's calculations.
44100 / 16 / stereo 3:08:58 3:18:09 0:09:11
44100 / 24 / stereo 2:05:59 2:12:06 0:06:07
48000 / 16 / stereo 2:53:37 3:02:03 0:08:26
48000 / 24 / stereo 1:55:44 2:01:22 0:05:37
82000 / 16 / stereo 1:34:29 1:39:04 0:04:35
82000 / 24 / stereo 1:02:59 1:06:03 0:03:04
96000 / 16 / stereo 1:26:48 1:31:01 0:04:13
96000 / 24 / stereo 0:57:52 1:00:41 0:02:49
It's a difference of 4.85% more recording time per file. Again sure I wish I had it too just in case but I'm not overly bummed about it.
J.T.
i guess i don't get this stuff
i got a MT today and with a 4gb microdrive i am told i have 2:56.46 on 16 bit/(auto)
and 1:58.00 on 24 bit/(auto)
if i change from spdif to 1/8 i get
3:55.45 on 24/48
6:24.24 on 16/44.1
at any rate thanks for the time help
-
Don't have a microtrack anymore... But if I remember right when set to record digital/auto the MT gives you the time remaining at 96k. Sort of a worst case scenero. That may change when you feed it a signal and it knows what sampling rate its set at. When it records analog it knows what sampling rate ahead of time so it can give you a accurate estimate.
Here is a link on how to calculate sizes at different rates:
http://24bit.turtleside.com/pcm.wav.file.sizes.pdf (http://24bit.turtleside.com/pcm.wav.file.sizes.pdf)