On 9.12.2014 20:31, Janne Hyvärinen wrote:
> On 25.11.2014 12:14, Miroslav Lichvar wrote:
>> I think the case with non-zero partition order may need to be fixed
>> too. For example, with partition order of 1, predictor order of 16 and
>> blocksize of 4, the function would return true and blocksize-order in
>> the caller would still underflow.
>>
>> --- a/src/libFLAC/stream_decoder.c
>> +++ b/src/libFLAC/stream_decoder.c
>> @@ -2744,7 +2744,7 @@ FLAC__bool
>> read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne
>> if(partition_samples < predictor_order) {
>> send_error_to_client_(decoder,
>> FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC);
>> decoder->protected_->state =
>> FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
>> - return true;
>> + return false;
>> }
>> }
>>
>> Thoughts?
> This patch breaks seeking in some perfectly valid files. So far I have
> received one sample full CD image from a foobar2000 user where a track
> is rendered inaccessible because of this. Re-encoding the file with FLAC
> 1.2.1 - 1.3.1 with identical settings doesn't remove the seeking problem.
> Either this patch needs to go or it needs to be altered to not prevent
> seek sync.
>
>
In general I'm against patches that error out at the first sign of
corruption instead of gracefully handling the situation and continuing
from the next good bytes. I think it would be better to let the decoder
continue its work when possible and perform input validation where it's
relevant.
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
