Topic: Archos Gmini 120

[jerryfreak]

bunch of things here:

I did a longer test with the ad2k>gmini today, and got the following results:
48K wav
3:21:00
14 misplaced samples
2 regions of errors, consisting of bursts of random digital noise increasing in length, then finally resuming normal recording.

it will continue to record over 2gb, but it wont have a proper header, and you'll need to open it in .raw mode.

a thought on the 'recording silence' tests. You will notice that a lot of the misplaced samples are either -inf (0) or full scale digital (1). By recording silence, you wouldnt notice misplaced zero samples, so the test is flawed by definition.

FWIW, 12 misplaced samples in over 3 hours of recording is not really evidence of hd spin up interference. the entire notion of such a thing is a bit silly, you dont think they would address that with a hard-drive based mp3 player? it would occur on playback as well.

[jerryfreak]

I spoke to someone at Archos, who told me that all of the firmware is written by engineers in france. I was able to get an email of a technical contact over there, and sent him the email below. Hopefully, if he's not the person, it will get to the right person.

Hello xxxxx,
 I was given your contact information from the American division of Archos. I
am looking to establish a technical contact in order to discuss issues with
the Gmini 120. Ideally, it would be most efficient if I could speak to the
engineer(s) in charge of writing firmware revisions and plug-ins. If youre not
the right person, if you could forward this along it would be greatly
appreciated.

There is a large group of consumers who are currently without an acceptable
product for mobile recording of .wav files from a S/PDIF source. Many former
DAT (digital audio tape) users have switched to using laptops to record audio
in mobile environments. While this works well, and offers both higher
resolution and the advantages of hard disk recording, portability and powering
become issues.

For several years, the market has been ready for hard-disk recorders. At this
point, the designs available fall into one of two categories:

1)professional units that are too large and/or too expensive for the average semi-
pro or hobby recordist:

http://www.sounddevices.com/products/7.htm
http://www.oade.com/digital_recorders/hard_disc_recorders/hhb_portadrive.html
http://www.zaxcom.com/audio/deva.shtml

2)consumer mp3 player/recorder units which offer the correct functionality,
but reliability is not suitable for recording use:

http://www.creative.com/products/product.asp?prodid=296  (recording glitches)
http://www.iriveramerica.com/products/iHP-120.asp  (limited to 800mb files)

At this point, there are no affordable solutions for recording spdif audio reliably at 16-bit, and no affordable options at all for recording 24-bit spdif. Based on Archos' history of responding to consumer demands and providing advanced functionality, I have hope that the Gmini 120 can be revised through software to enable these applications.

There are a handful of people who have been testing the .wav recording functionality of the Gmini 120, and all report similar problems to various degrees. The following tests were done with another relaible spdif recording device (soundcard or dat) in parallel to isolate the problem to the Gmini:

1) the device will write 'misplaced' samples in one or both channels. The net result of this is a point far off the waveform, which results in a steep slope in the waveform and an audible 'pop' or 'click' when played back

2) the device will record random digital noise instead of the actual waveform. The pattern of error is similar from instance to instance. After these short bursts of digital noise, the device resumes recording normally

I would like to offer our assistance in testing future firmware releases in order to alleviate these issues. We are offering this service and requesting no compensation, our only goal is to further the advancement of the technology. If the Gmini can be proven to be a reliable .wav recorder, we would be glad to promote it as such to our colleagues, which would result in increased sales for your company.

Resolving the recording issues are a priority for us, beyond that, there is another list of firmware requests, such as:

-proper playback of .wav files without gaps or glitches between tracks
-adoption of the .flac codec, an open source lossless codec
-support for 24-bit recording
-support for recording at higher sample rates (96K or above)
-quick starting of another file when recording, without the 5-10 second period of lost audio between files.


I look forward to hearing from you!


----------------------------------

[Brian Skalinder]

Nice, Jamie - let us know how it goes!

(Though with respect to the NJB3 unreliability, my V3 AES/EBU > Hosa ODL-312 > NJB3 has been bulletproof so far.  YMMV.)

[JasonSobel]

Jamie,
yes, definitely keep us updated.  I've written similar emails to their tech support, but I'm guessing that the right person hasn't read them yet.  hopefully yours will get through.

[Riley]

This is kind of off the subject of testing, but I have a couple of questions for anyone that might know about making a digital cable for the Gmini.

First, I wanted to build a better cable for the Gmini for just digital input (RCA to 1/8" mini), so that I wouldn't have all the loose ends flapping in the breeze like on the cable that came with it.  I spent some time with a multimeter and determined that there really isn't a way to do it without one of those special 4-contact 1/8" mini plugs like is used on the factory cable.  Anyone know where I could pick up just the end for a 4-contact mini plug?

Also, there was some discussion earlier about a digital cable being 75 ohms.  What exactly is meant by that.  Both the digital cable that I use for DAT recording and the cable that came with the Gmini register really low (0.1 or 0.2 ohms) using a Fluke 87 III.  So, what's the story with the 75 ohms?

Riley

[JasonSobel]

I just checked something on my earlier tests.  from one of the images I posted of the EAC compare .wav results, it listed the times at which the glitches occur.

similar to Riley, all of those glitches occur either 19.3 seconds apart, or some multiple of 19.3
primarily multiples of 1, 2 or 3.  but some at intervals of 5 or 6 times the 19.3 second interval.  one glitch even at 3:51.8 from the previous glitch, or exactly 12 multiples of 19.3 seconds apart.   for whatever reason, at that time interval, it appears as though the gmini is more likely to record a misplaced sample.  although it sometimes get's it right and gets through that time period with no problems at all...

hopefully archos will be able to get this figured out.  I sent them another email with this information as well.  hopefully it won't fall upon deaf ears.

[Riley]

+T Jason!

Wow, I'm really glad to see that this was verified by someone else.  I really spent a lot of time poking around the data trying to find some kind of correlation between the pops.  I'm happy that it payed off.

Now, were you recording at 44.1 kHz or 48?

Riley

[JasonSobel]

Riley,
that particular test was done at 44.1 kHz.   on page 7 of this thread.
Reply #93 on: January 15, 2004, 10:23:55 PM
I posted a picture with EAC's wave compare results.  I just grabbed those numbers from the posted picture and did the math.  the first glitch is not at an interval of 19.3, presumably because I had trimmed the start of the file to match exactly with the file recorded on my computer to do the bit-accuracy tests...

[Brian Skalinder]

Good stuff, guys...keep pressing on!

[Riley]

Jason,

Here's another thing you might mention to Archos to add.  Tell them to make it so you can use the backlight feature while recording.  This would come in really handy at a dark show if you forgot your flashlight or something.

Riley

[timP]

aside: I know this isn't at all the same as the ARCHOS, but here is link to some pics that a German dude took of the inside of his IRIVER 120 HD player. Just and idea maybe of what's going on underneath the cover  of our Archos..
http://www.ihplounge.com/ihpviews.htm

[jerryfreak]

reply from archos:

Dear Mr. Lutch,
Thank you for your observations.  I will forward your e-mail to the
appropriate people.  Despite the advantages of your suggestions, and perhaps
further sales, this is not presently in our business plan to add such
options. I am of course interested in what appears to be incorrect WAV
recording and I will forward this to the Engineers that if indeed it is a
bug, that it be resolved.  Thank you for your offer to help us test, but at
this time we are not taking on additional test sites.

For your list, here is what I can tell you:
>
> -proper playback of .wav files without gaps or glitches between tracks
        We will investigate this
> -adoption of the .flac codec, an open source lossless codec
        We have no plans at present to add this functionality
> -support for 24-bit recording
        We have no plans at present to add this functionality
> -support for recording at higher sample rates (96K or above)
        We have no plans at present to add this functionality
> -quick starting of another file when recording, without the 5-10 second
period
> of lost audio between files.
        This product noes not have the "next" feature that our Jukebox Multimedia
has when recording audio.  The next feature allows a new recording with a
1-2 second loss in recording time.

I am sorry I cannot offer you what you are looking for, but I think you can
understand that we have certain business plans that we want to stick to.

xxxx xxxxxxxx
Quality Engineer

[WizDawg]

I've had the same results with my Gmini 120 recording via spdif.  No pops with analog.   I wonder if the problem is with the multi-connect adapter plug??  Hmm, whatever the problem is I hope they can fix it.

Mike

[Ed.]

thats kinda shitty on the reply back from the company, but it just shows you more that they only care about selling to the masses and catering to mp3s.  However, the way he talks, all the things we want done can be done thru firmware.  I wonder if there is a way that we could make our own firmware updates.  I'm sure if enuf geeks put their noggins together, something could come of this.   We just need the brains and the dedication.  but then again, would it be worth it?

ed

[jerryfreak]

well, I see where he's coming from, you cant implement all requests (tho i wish they would )

as for hacking the firmware, it might be possible, depending on what language its written in. but I would expect some help from archos would be necessary to make sense of it, and theyre not exactly big into open source solutions from what I can tell.

an engineer did get back to me, I forwarded him clips of the errors as short .wavs, and mentioned the '19.3 second rule'  

I am confident that we have a good dialogue going, tho!