[bookport] Re: Suggestions for Improvements to Book Port - Others' Input and Discussion Requested
- From: Jeremiah Z Rogers <jzrogers@xxxxxxxxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Tue, 11 May 2004 10:31:03 -0400
Hi Rob et al. I mustn't have been particularly clear in my explanation of how
to achieve the proposed desired behavior when dealing with MP3 files, for I
realize that the machine, at present, has no way of knowing whether or not to
keep track of its progress as it plays a file. What I think could be done would
be for the transfer tool to indicate, through mark-up, to the machine that it
need not keep track of its play progress as it plays an MP3 file. As a result
of there not being data on what part of a file has or hasn't been played, the
machine would start at the beginning of the file every time. Were the presence
of this new mark-up to be directly related to the status of the send audio
files as music option, users would have means of determining whether or not
Book Port would behave as it does now, or more like a traditional CD player.
Hope that clears up my idea a bit.
Jeremiah
>
> From: "ROB MEREDITH" <rmeredith@xxxxxxx>
> Date: 2004/05/10 Mon AM 08:27:53 EDT
> To: <bookport@xxxxxxxxxxxxx>
> Subject: [bookport] Re: Suggestions for Improvements to Book Port -
> Others' Input and Discussion Requested
>
> Jeremiah:
>
> You are missing one detail in your MP3 mark-up discussion. That is, the =
> device doesn't know whether the file was sent as music or spoken word. =
> Both files are actually marked up; the difference is in the mark-up =
> itself. Music uses recurring marks to simulate movement by time; spoken =
> word mark-up marks phrases.
>
> >>> jzrogers@xxxxxxxxxxxxx 05/10/04 06:35AM >>>
> Greetings to all ye Book Porters
>
> A few weeks back, there were a number of messages surrounding Book =3D
> Port's behavior when playing MP3 audio, where it leaves markers once it =
> =3D
> has played the file, etc. I didn't weigh in on the discussion at that =3D
> point, because I wanted to think over the idea I had and to decide =3D
> whether or not the practicality of it warranted suggesting it to APH for =
> =3D
> consideration. Please do point out, publicly or privately, the positives =
> =3D
> and negatives you find in the following thoughts.
>
> At present, the transfer tool allows the user the option of specifying =3D
> whether mp3 audio is sent to the machine as music, which is to say that =
> =3D
> it is unmarked, or to have the software deduce breaks in paragraphs, =3D
> chapters, and other navigational units. Many of you were asking for a =3D
> means of resetting all of the markers within a given folder such that =3D
> you could start at any given point in the list of files and have the =3D
> files play, starting from the beginning, in exactly the same fashion as =
> =3D
> would occur when using a commercial CD player. Seemingly with little =3D
> modification of the Book Port's firmware, and perhaps with only slight =3D
> modification to the transfer tool, APH could instruct the device not to =
> =3D
> keep track of where it left off playing a given file if that file were =3D
> sent as music, while still retaining the device's present behavior for =3D
> audio files which were sent allowing the transfer tool to mark them up. =
> =3D
> If, for some reason, one wanted to start at a given point other than the =
> =3D
> beginning of a sent-as-music file, they could still use the device's =3D
> marking features.
>
> Concerning a separate issue altogether, I also have a suggestion for how =
> =3D
> the Book Port behaves once locked and powered off. At present, if any =3D
> key other than the 1+3 combination is pressed, the machine emits that =3D
> all-too-familiar half-second or so buzz, waits the customary ten seconds =
> =3D
> or so of inactivity, then powers off. Over the course of half an hour in =
> =3D
> one's pocket, briefcase, or other location of transportation, this could =
> =3D
> happen dozens of times, and could cause lots of disruption to those =3D
> around the device with that annoying beep. My suggestion, then, is to =3D
> have the lock and unlock command be a combination of keys, and to have =3D
> the machine's behavior when the unit is locked and not reading to be =3D
> completely unresponsive to keys or key combinations other than the =3D
> command chosen as the unlock command. Further, I suggest that the unlock =
> =3D
> command be a combination of keys other than on the same row or column. I =
> =3D
> suggest 1+F, given that they'd take two hands to invoke and that it =3D
> shouldn't interfere with any of the present command structure.
>
> I look forward to reading any insuing discussion in response to these =3D
> thoughts.
>
> Jeremiah Z. Rogers, jzrogers@xxxxxxxxxxxxx=20
>
>
>
>
>
>
Other related posts:
