Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
[Prev][Next][Index][Thread]
Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
you are talking about splicing the mpeg file to fit it in certain
spaces, korrect?
>From: "Jon Olson" <morph@jmss.com>
>To: <ti-hardware@lists.ticalc.org>
>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>Date: Wed, 4 Nov 1998 20:01:31 -0500
>Reply-To: ti-hardware@lists.ticalc.org
>
>
>no...a bitmap would be quite fast actually, it's what some operating
systems
>(QNX for example) use for free block checking. I do agree that periodic
>defragging is good, but having it so that you can't send over any more
mp3s
>if you don't have a free block large enough to hold them? that's what i
>considder silly. Using a bitmap, you would be able to quickly find the
free
>space needed to store the mp3, and have a few bytes in the header, as
well
>as a flag bit saying "file fragment, more stored here", and then on the
last
>fragment have a "final fragment." It's fast, and wouldn't require very
much
>codespace to implement. It's certainly fast enough to stream audio this
way.
>(and far faster than the parallel/serial port, so sending data over
wouldn't
>be hurt at all)
>
>-- Jon Olson
>
>-----Original Message-----
>From: Nick S [despuqué] <worldsnow@hotmail.com>
>To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
>Date: Wednesday, November 04, 1998 7:57 PM
>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>
>
>>
>>umm... maybe you could /program/ it to do that, but in the real
>>hardware, that is silly (best word I could use without offending your
>>mother)... the hdd would be slower than slow, I mean it either a) MUST
>>be defragged or b) do what dave said and fit mp3's into deleted mp3
>>slots...
>>
>>>From: "Jon Olson" <morph@jmss.com>
>>>To: <ti-hardware@lists.ticalc.org>
>>>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>>>Date: Wed, 4 Nov 1998 17:15:55 -0500
>>>Reply-To: ti-hardware@lists.ticalc.org
>>>
>>>
>>>god no...we shouldn't have to worry about defragmenting it,
especially
>>if
>>>you're keeping it in-circuit...a fairly easy file system consiting of
a
>>>bitmap that says which blocks are used would be efficent, easy to
>>program,
>>>and eliminate the need for such software (would would undoubtedly be
>>very
>>>slow since i doubt this takes advantage of PIO/UDMA
>>>
>>>-----Original Message-----
>>>From: ns [despuqué] <worldsnow@hotmail.com>
>>>To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
>>>Date: Wednesday, November 04, 1998 5:14 PM
>>>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>>>
>>>
>>>>
>>>>oh of course it needs a file system, I just meant not like HPFS or
>>>>FAT... although I think it will be a write once type of thing, or
>>>>"concatonate" files on the end... if it gets big enough then there
>>will
>>>>definately be relocation software, that is "defrag" sofware.
>>>>
>>>>>From: "David Knaack" <dknaack@hotmail.com>
>>>>>To: ti-hardware@lists.ticalc.org
>>>>>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>>>>>Date: Wed, 04 Nov 1998 13:47:49 PST
>>>>>Reply-To: ti-hardware@lists.ticalc.org
>>>>>
>>>>>
>>>>>>From: "ns [despuqué]" <worldsnow@hotmail.com>
>>>>>>It isn't necessary to have a file system, unless you want to
remove
>>>>the
>>>>>>HDD from the mp3 player and mount it directly to a computer...
>>>>>
>>>>>Depends on what you mean by file system. By file system
>>>>>I mean an organizational system by which the player can
>>>>>keep track of its MP3 data. I believe that this falls
>>>>>under the definition of a "file system" albet a simple one.
>>>>>
>>>>>I'd set up about the first 50k-100k of the disk as an
>>>>>allocation table, containing up to 500 blocks of about
>>>>>200 bytes to describe the song info and data start and
>>>>>end positions on the disk. This would give you up to
>>>>>about 500 songs on the player.
>>>>>
>>>>>Fragmentation wouldn't be a big deal for most people,
>>>>>as I wouldn't expect too much shuffling of songs, but
>>>>>the player should try to fit songs into any gaps in the
>>>>>system, to keep free space fragmentation to a minimum.
>>>>>Deleting a song would be as simple as marking the first
>>>>>character in its allocation block with a special character.
>>>>>When new songs are to be added the MP3 player would
>>>>>simply scan the allocation table for a free block, when
>>>>>it found one it would check to see if it had been
>>>>>previously used (start and end pointers not null), and
>>>>>if so, verify that the space is long enough. If so it
>>>>>would use that block, if not it would continue scanning.
>>>>>
>>>>>With lots of adding and deleting it would eventually be
>>>>>necessary to defragment the free space, but that could
>>>>>be as simple as writing the entire data structure to the
>>>>>computer, formatting the allocation table and writing
>>>>>the data back. Might take a while with a gig of data.
>>>>>Alternately someone could write a free space defragmenter
>>>>>for it (pretty easy, just scan the allocation table for
>>>>>gaps between the end pointer of a song and the start of
>>>>>the next song, if found, copy the data backwards into
>>>>>the gap and reset the start/end pointers, then go to
>>>>>the next song.
>>>>>
>>>>>DK
>>>>>
>>>>>______________________________________________________
>>>>>Get Your Private, Free Email at http://www.hotmail.com
>>>>>
>>>>
>>>>
>>>>______________________________________________________
>>>>Get Your Private, Free Email at http://www.hotmail.com
>>>>
>>>
>>>
>>
>>
>>______________________________________________________
>>Get Your Private, Free Email at http://www.hotmail.com
>>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com