[bookport] Re: Music/text audio files - the file pointer issue& lock feature
- From: "Rich Hartness" <hartness@xxxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Thu, 13 May 2004 21:07:51 -0400
Rob stated:
> It is also notable that more portable music CD/MP3 players are remembering
=
> your last position, and starting from there instead from the beginning of
=
> the disc, or from the beginning of the last played track. Mine does this,
=
> and it never bothered me in the least.
So these devices return you back to the position of the last track that was
being played. Once it finishes that track it goes on to the beginning of
the next track instead of where you may have left that second track and
subsequent tracks.
One important uniqueness of the Bookport when compared to other commercial
music players is that it recalls and uses the mid file pointer position for
every file. Contrastingly, commercial players recall and use the mid file
position of only the last piece that was played.
Comments?
Rich
----- Original Message -----
From: "ROB MEREDITH" <rmeredith@xxxxxxx>
To: <bookport@xxxxxxxxxxxxx>
Sent: Thursday, May 13, 2004 9:46 AM
Subject: [bookport] Re: Music/text audio files - the file pointer issue&
lock feature
> I guess I am wondering what happens when a user prefers to pause a music =
> file? Jeremiah's suggestion would place the user back at the beginning of
=
> the file every time. The way it is now, the user has a choice. Should I =
> listen from where I was, or should I hold down 1 to get to the beginning.
>
> It is also notable that more portable music CD/MP3 players are remembering
=
> your last position, and starting from there instead from the beginning of
=
> the disc, or from the beginning of the last played track. Mine does this,
=
> and it never bothered me in the least.
>
> Rob Meredith
>
> >>> hartness@xxxxxxxx 05/13/04 09:15AM >>>
> Hi Larry and list,
>
> A few weeks ago Jeremiah said:
>
> "APH could instruct the device not to keep track of where it left off
> playing a given file if that file were sent as music, while still =
> retaining
> the device's present behavior for audio files which were sent allowing the
> transfer tool to mark them up."
>
> I think what Jeremiah is saying here is a perfect compromise. It's =
> totally
> up to the user at the time of the file transfer to decide whether an audio
> file is treated as music or as text based. In other words The user can =
> have
> it either way with audio files. Text based audio files would behave with
> all the advantages of being able to start where you left off. Music based
> files would behave consistently with all other commercial music players
> starting each time from the beginning. It's totally up to the user how an
> audio file is treated.
>
> Hey, this is cake and eat it too... This would give Bookport a five star
> rating as both a reading device and music player in my book.
>
> On another topic, I agree with Jeremiah's quiet 2 key lock solution. I'm
> always hearing that beep beep beep of the keys getting accidentally =
> pressed
> while it's riding locked in my shoulder bag.
>
> I really love the Bookport. Larry and Co are doing a great job.
>
> I also admire the group of users who have expressed themselves here. =
> Posts
> have been most relevant. Great signal to noise ratio. Thanks all!
>
> Gratefully,
>
> Rich
> Greensboro NC
> ----- Original Message -----=20
> From: "LARRY SKUTCHAN" <lskutchan@xxxxxxx>
> To: <bookport@xxxxxxxxxxxxx>
> Sent: Thursday, May 13, 2004 7:56 AM
> Subject: [bookport] Re: Suggestions for Improvements to Book Port- Others'
> Input and Discussion Requested
>
>
> > What do you think of the idea of just letting each file resume from =
> where
> =3D
> > you left it, but if you press play when at the end of the file, Book =
> Port
> =3D
> > would start from the beginning. At worst, you could have left a song, =
> =3D
> > then when you go back, it resumes from that point, but you can still =
> press
> =3D
> > 1 for one beep to reset to the top in the rare occasions when this will
=
> =3D
> > happen. =3D20
> >
> >
> >
> > >>> jzrogers@xxxxxxxxxxxxx Wednesday, May 12, 2004 6:01:13 PM >>>
> > Hello Dave and list. Indeed, were APH to change the behavior of the =
> =3D3D
> > machine according to what I've suggested, such that it played music =
> =3D3D
> > files without keeping track of where you stopped, while still playing =
> =3D3D
> > files which were not sent as music the wya it does now, you could still
=
> =3D
> > =3D3D
> > have it behave as your Rio does when playing Audible books, and behave =
> =3D3D
> > more like a traditional CD player when playing music. It would eliminate
=
> =3D
> > =3D3D
> > the need to reset files which were sent as music back to their beginning
=
> =3D
> > =3D3D
> > before playing them again.
> > Jeremiah
> >
> >
> > -----Original Message-----
> > .From: "Dave Cunningham "<dcj638586@xxxxxxxxxxx>
> > .Sent: 5/11/04 11:30:19
> > .To: "bookport@xxxxxxxxxxxxx"<bookport@xxxxxxxxxxxxx>
> > .Subject: [bookport] Re: Suggestions for Improvements to Book Port - =3D
> > =3D3D
> > Others' Input and Discussion Requested
> > .
> > .Hello,
> > .The thing is if someone was to be listening to an audible book, which =
> =3D3D
> > is
> > .quite large, will the book port remember where it was if you stopped =
> =3D3D
> > it =3D3D3D
> > .and
> > .started it later? I would hope so. I would hate to have to search =
> =3D3D
> > =3D3D3D
> > .every
> > .time I started the book port for where I left off when reading a book.
> > .Also, I would find it cumbersome to use bookmarks to mark the spot. =
> =3D3D
> > =3D3D3D
> > .When I
> > .used my RIO I just pressed the button to restart where I left off, no =
> =3D3D
> > =3D3D3D
> > .matter
> > .where I was or how long I left it, I could just simply pick it up =3D3D
> > press =3D3D3D
> > .the
> > .start button and off it would read exactly where I left off. No =
> =3D3D3D
> > .worries.=3D3D3D20
> > .
> > .Dave Cunningham
> > .(412) 257-8153 Home
> > .(412) 215-4597 Cell
> > .Email address used for MSN.
> > .=3D3D3D20
> > .All incoming and outgoing email scanned by Norton Anti-virus
2003=3D3D3D=
> 20
> > .
> > .
> > .-----Original Message-----
> > .From: bookport-bounce@xxxxxxxxxxxxx =3D3D3D
> > .[mailto:bookport-bounce@xxxxxxxxxxxxx]=3D20=20
> > .On Behalf Of Jeremiah Z Rogers
> > .Sent: Tuesday, May 11, 2004 10:31 AM
> > .To: bookport@xxxxxxxxxxxxx=3D20=20
> > .Subject: [bookport] Re: Suggestions for Improvements to Book Port - =
> =3D3D
> > =3D3D3D
> > .Others'
> > .Input and Discussion Requested
> > .
> > .
> > .Hi Rob et al. I mustn't have been particularly clear in my explanation
=
> =3D
> > =3D3D
> > =3D3D3D
> > .of
> > .how to achieve the proposed desired behavior when dealing with MP3 =
> =3D3D3D
> > .files,
> > .for I realize that the machine, at present, has no way of knowing =
> =3D3D3D
> > .whether or
> > .not to keep track of its progress as it plays a file. What I think =
> =3D3D
> > could =3D3D3D
> > .be
> > .done would be for the transfer tool to indicate, through mark-up, to =
> =3D3D
> > the
> > .machine that it need not keep track of its play progress as it plays =
> =3D3D
> > an =3D3D3D
> > .MP3
> > .file. As a result of there not being data on what part of a file has =
> =3D3D
> > or
> > .hasn't been played, the machine would start at the beginning of the =
> =3D3D
> > file
> > .every time. Were the presence of this new mark-up to be directly =3D3D
> > related =3D3D3D
> > .to
> > .the status of the send audio files as music option, users would have =
> =3D3D
> > =3D3D3D
> > .means
> > .of determining whether or not Book Port would behave as it does now, =
> =3D3D
> > or =3D3D3D
> > .more
> > .like a traditional CD player. Hope that clears up my idea a bit. =
> =3D3D3D
> > .Jeremiah
> > .
> > .>=3D3D3D20
> > .> 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
> > .>=3D3D3D20
> > .> Jeremiah:
> > .>=3D3D3D20
> > .> You are missing one detail in your MP3 mark-up discussion. That =3D3D
> > is,=3D3D3D20
> > .> the =3D3D3D3D device doesn't know whether the file was sent as music
=
> or =3D
> > =3D3D
> > =3D3D3D
> > .spoken=3D3D3D20
> > .> word. =3D3D3D3D Both files are actually marked up; the difference is
=
> in =3D
> > =3D3D
> > the=3D3D3D20
> > .> mark-up =3D3D3D3D itself. Music uses recurring marks to simulate =
> =3D3D
> > movement by =3D3D3D
> > .
> > .> time; spoken =3D3D3D3D word mark-up marks phrases.
> > .>=3D3D3D20
> > .> >>> jzrogers@xxxxxxxxxxxxx 05/10/04 06:35AM >>>
> > .> Greetings to all ye Book Porters
> > .>=3D3D3D20
> > .> A few weeks back, there were a number of messages surrounding Book =
> =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D=3D3D3D20
> > .> Port's behavior when playing MP3 audio, where it leaves markers =3D3D
> > once=3D3D3D20
> > .> it =3D3D3D3D =3D3D3D3D3D has played the file, etc. I didn't weigh in
=
> on the
> =3D
> > =3D3D
> > =3D3D3D
> > .discussion=3D3D3D20
> > .> at that =3D3D3D3D3D point, because I wanted to think over the idea I
=
> had
> =3D
> > =3D3D
> > and =3D3D3D
> > .
> > .> to decide =3D3D3D3D3D whether or not the practicality of it =3D3D
> > warranted=3D3D3D20
> > .> suggesting it to APH for =3D3D3D3D =3D3D3D3D3D
> > .> consideration. Please do point out, publicly or privately, the =
> =3D3D3D
> > .positives =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> and negatives you find in the following thoughts.
> > .>=3D3D3D20
> > .> At present, the transfer tool allows the user the option of =3D3D
> > specifying =3D3D3D
> > .
> > .> =3D3D3D3D3D whether mp3 audio is sent to the machine as music, which
=
> is =3D
> > =3D3D
> > to =3D3D3D
> > .say=3D3D3D20
> > .> that =3D3D3D3D =3D3D3D3D3D it is unmarked, or to have the software =
> deduce =3D
> > =3D3D
> > breaks =3D3D3D
> > .in=3D3D3D20
> > .> paragraphs, =3D3D3D3D3D chapters, and other navigational units. Many
=
> of =3D
> > =3D3D
> > you=3D3D3D20
> > .> were asking for a =3D3D3D3D3D means of resetting all of the markers =
> =3D3D
> > within a =3D3D3D
> > .
> > .> given folder such that =3D3D3D3D3D you could start at any given point
=
> in
> =3D
> > =3D3D
> > the =3D3D3D
> > .
> > .> list of files and have the =3D3D3D3D3D files play, starting from =
> =3D3D
> > the=3D3D3D20
> > .> beginning, in exactly the same fashion as =3D3D3D3D =3D3D3D3D3D
> > .> would occur when using a commercial CD player. Seemingly with little
=
> =3D
> > =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> modification of the Book Port's firmware, and perhaps with only =3D3D
> > slight =3D3D3D
> > .=3D3D3D3D3D
> > .> modification to the transfer tool, APH could instruct the device not
=
> =3D
> > =3D3D
> > =3D3D3D
> > .to =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> keep track of where it left off playing a given file if that file =
> =3D3D
> > were =3D3D3D
> > .=3D3D3D3D3D
> > .> sent as music, while still retaining the device's present behavior =
> =3D3D
> > for =3D3D3D
> > .=3D3D3D3D3D
> > .> audio files which were sent allowing the transfer tool to mark them =
> =3D3D
> > =3D3D3D
> > .up. =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> If, for some reason, one wanted to start at a given point other than
=
> =3D
> > =3D3D
> > =3D3D3D
> > .the =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> beginning of a sent-as-music file, they could still use the device's
=
> =3D
> > =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> marking features.
> > .>=3D3D3D20
> > .> Concerning a separate issue altogether, I also have a suggestion =
> =3D3D
> > for=3D3D3D20
> > .> how =3D3D3D3D =3D3D3D3D3D the Book Port behaves once locked and =
> powered =3D
> > off. =3D3D
> > At=3D3D3D20
> > .> present, if any =3D3D3D3D3D key other than the 1+3 combination is =
> =3D3D
> > pressed, =3D3D3D
> > .the=3D3D3D20
> > .> machine emits that =3D3D3D3D3D all-too-familiar half-second or so =
> buzz, =3D
> > =3D3D
> > =3D3D3D
> > .waits=3D3D3D20
> > .> the customary ten seconds =3D3D3D3D =3D3D3D3D3D
> > .> or so of inactivity, then powers off. Over the course of half an =
> =3D3D
> > hour =3D3D3Dawhether or not Book Port would behave as
> > .in =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> one's pocket, briefcase, or other location of transportation, this =
> =3D3D
> > =3D3D3D
> > .could =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> happen dozens of times, and could cause lots of disruption to those =
> =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> around the device with that annoying beep. My suggestion, then, is =
> =3D3D
> > to =3D3D3D
> > .=3D3D3D3D3Dase
> > .> have the lock and unlock command be a combination of keys, and to =
> =3D3D
> > have =3D3D3D
> > .=3D3D3D3D3D
> > .> the machine's behavior when the unit is locked and not reading to be
=
> =3D
> > =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> completely unresponsive to keys or key combinations other than the =
> =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> command chosen as the unlock command. Further, I suggest that the =
> =3D3D
> > =3D3D3D
> > .unlock =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> command be a combination of keys other than on the same row or =3D3D
> > column. =3D3D3D
> > .I =3D3D3D3D
> > .> =3D3D3D3D3D
> > .> suggest 1+F, given that they'd take two hands to invoke and that it =
> =3D3D
> > =3D3D3D
> > .=3D3D3D3D3D
> > .> shouldn't interfere with any of the present command structure.
> > .>=3D3D3D20
> > .> I look forward to reading any insuing discussion in response to =3D3D
> > these=3D3D3D20
> > .> =3D3D3D3D3D thoughts.
> > .>=3D3D3D20
> > .> Jeremiah Z. Rogers, jzrogers@xxxxxxxxxxxxx=3D3D3D3D20=3D20=20
> > .>=3D3D3D20
> > .>=3D3D3D20
> > .>=3D3D3D20
> > .>=3D3D3D20
> > .>=3D3D3D20
> > .>=3D3D3D20
> > .
> > .
> > .
> > .
> > .
> >
> >
> >
>
>
>
>
Other related posts:
