[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-filesystem-dev
Subject:    [hxfilesys] Re: [hxdatatype] Re: [hxfilesys] Fix for MP3 fileformat and
From:       Eric Hyche <ehyche () real ! com>
Date:       2003-06-30 18:02:55
Message-ID: 5.1.0.14.2.20030630140117.00b86608 () mailone ! real ! com
[Download RAW message or body]


I was just speculating about garbage showing up in the TAC
information - I haven't looked at the TAC parsing code. My
point was just that this bug hasn't been caught earlier because
the read after the failed seek will probably still succeed.

Eric

At 10:23 AM 6/30/2003 -0700, Chris Sloan wrote:
>The seek failed changes looks good but I have a couple questions
>below.
>
>Monday, June 30, 2003, 10:09:34 AM, you wrote:
>
>
>Eric> dev@datatype and dev@filesystem:
>
>Eric> Attached is a diff which fixes a problem in the mp3 fileformat.
>Eric> Fixing this problem in the mp3 fileformat uncovered a bug
>Eric> in the http filesystem. The fix for the httpfsys bug is
>Eric> also included in the same diff.
>
>Eric> Here was the problem. On the ID3 seek to close to the end of the
>Eric> file, the mp3 fileformat was ignoring the status returned in
>Eric> the SeekDone() calls and going ahead and trying to blindly read
>Eric> the ID3 tags. Not good. I suppose this bug was not discovered before
>Eric> due to the fact that: a) Seeks rarely fail; and b) most of the time
>Eric> if you went ahead and read after a seek failed, you wouldn't crash -
>Eric> you would simply get garbage for the ID3 tag information. In normal
>Eric> playback, you'd still hear the mp3 file playing although the TAC 
>information
>Eric> would look funny.
>
>If the id3 seek failed and the ff issued a read, the file system would
>read from the beginning of the file, right?  The mp3 ff then calls a
>function to extract the id3 values from the read buffer, but if the id3
>tag is not present, it will not extract any values.  I don't see how
>garbage id3 values were given to TAC if none were pulled from the read
>buffer. Can you explain?
>
>Chris
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@datatype.helixcommunity.org
>For additional commands, e-mail: dev-help@datatype.helixcommunity.org

======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@filesystem.helixcommunity.org
For additional commands, e-mail: dev-help@filesystem.helixcommunity.org


[prev in list] [next in list] [prev in thread] [next in thread]