#339 seek bug

1.3.0
closed-works-for-me
Erik
libFLAC (59)
6
2015-10-05
2008-10-22
john doe
No

I've written a DJ app that can play audio files in reverse. To do that one must ofcourse jump to some seek position read a big block and then play it reverse, then again read a big block prior to the last one and also play it reverse, asf..
With FLAC, this creates artefacts (jumps/stotters/clicks) in the audio around the seek positions, so there is something wrong with the seek itself or the decoding after setting a new seek position.
Either way, this makes FLAC quite unusable for DJ apps

Discussion

  • john doe

    john doe - 2008-10-22
    • priority: 5 --> 6
     
  • Josh Coalson

    Josh Coalson - 2009-01-01
    • labels: --> libFLAC
    • assigned_to: nobody --> jcoalson
    • status: open --> open-works-for-me
     
  • Josh Coalson

    Josh Coalson - 2009-01-01

    I'll need a way to reproduce this. all testing indicates that seeks are sample-accurate.

    the best is if you have a small program that uses libFLAC to read blocks in reverse and an input file that demonstrates non-accurate seeking.

     
  • john doe

    john doe - 2009-09-25

    I just read somewhere that FLAC__stream_decoder_seek_absolute (decoder, (FLAC__uint64) reservoirStart); will not only seek to the given position, but actually also internally call FLAC__stream_decoder_process_single(), which is not documented. That may be the reason why my code never worked as it should.
    Is this corrent?

     
  • Erik

    Erik - 2014-03-21

    Is this still an issue?

     
  • Erik

    Erik - 2014-03-21
    • assigned_to: Josh Coalson --> Erik
    • Group: --> 1.3.0
     
  • Erik

    Erik - 2015-10-05
    • status: open-works-for-me --> closed-works-for-me
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks