[bookport] Re: Probably a very ancient question
- From: "ROB MEREDITH" <rmeredith@xxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Thu, 09 Mar 2006 10:54:27 -0500
Andrew:
The channel reversal is a design flaw. I don't think it is as simple as
swapping bit order around to fix it. A possible fix is to do it in Book
Port Transfer, but since many people including yourself bypass it, this
would be a waist.
I recommend a hardware fix at this point. Either a pair of headphones
which can be warn either way, or an adapter as discussed on this list
should do the trick.
Rob Meredith
>>> ahart@xxxxxxxxxxxxx 03/09/06 10:38AM >>>
Hi folks,
I've ben using the BP for more than a year now. it's a pretty useful
little beasty, which I recently had to ship back to APH for repairs
because it gratuitously upped and died on me. Despite the fact they
needed to send it back to Springer Design, they returned it in only 4
weeks from the date I shipped it, which is not bad going considering
they told me it can take up to five weeks to get a repair done if it
has to be shipped back to the factory and the mail often takes two
weeks to reach me from the States. Anyway, thanks again APH for the
repair work. I was pleasantly surprised to find it waiting for me
when I returned home from holidays. It's muchly appreciated.
However, I want to ask a question that I am sure has been asked many
times before on this list.
Why is it that the left and right channels are swapped on playback of
stereo Mp3 files? Such a basic flaw does surprise me somewhat. Does
the MP3 decoder use little endian while the CPU uses big endian
integers? Or did the DAC get wired upto the audio output the wrong
way round or something?
And would it be possible to provide a quick fix by swapping the
channels in software before pumping them to the DAC?
The Rockbox folks had to byte swap integers on the Archos line of
portable MP3 players in order to have their alternative firmware
produce correct output. The Archos' only had 12 MHz processors with
2 MB of RAM, the byte swapping was done with a small assembler
routine and I believe that battery life was not substantially
affected by the need to constantly preprocess the mp3 byte stream in
this way. From discussion of BP hardware limitations, I suspect that
the BP isn't significantly more powerful than the Archos
units. However, I haven't a single clue about what hardware is
inside the BP at all; I am merely guessing so it's highly probable
I'm talking threw my hat here.
I must admit I mainly use the Bookport for reading books, but it
would be nice to be able to listen to radio productions, movies and
music, etc., with the channels correctly allocated and without the
need to employ a hardware channel reverser. Such oversight of such a
basic property of the product does strike me as a significant bug
imho. i'mnot trying to apportion blame to anyone involved in BP
development; I'm merely just curious as to how it came about.
Please forgive me if this has previously been hashed to death on the
list, but I have only recently joined.
Or, another thought occurs to me. Maybe it's not the Book Port
that's at fault here. Is there something I might be doing wrong that
could be flipping the channels? I can't think what it could possibly
be. I generally move mp3 files to the BP via a flashcard
reader. USB 1.1 just doesn't cut it when moving anything other than
text files imho, which are fairly small. In fact, BPT is sometimes
slower processing the file so USB 1.1 isn't a big issue when dumping
books onto the unit, but I'm too impatient to sit around transfering
mp3's by any means short of USB 2.0.
Cheers,
Andrew.
Other related posts:
