Hi, I&#39;m working on an Ogg Vorbis port to an embedded platform.  One thing we&#39;ve found in QA is that if you have a file with a lot of bad pages (especially if they are stacked at the end of the file) it can take a very long time for the file to open.  After tracing the source code this appears to be due to how Ogg tries to find the last good page (the call to _get_prev_page() starting at the end of the file within open_seekable2()).  I think it starts by looking at the last page, and if it isn&#39;t valid it rewinds back a page.  If the 2nd to last page isn&#39;t valid it then again searches the last page rather than immediately kicking back to the 3rd to last page.  So what you end up with is a lot of extra searches, especially if there a lot of bad pages strung together at the end of the file.  I have a file with 125 bad pages and it something like 32000 checksum checks before getting to the actual good page.<br>
<br>Has anyone else run into this?  And assuming this analysis is correct, has anyone submitted a fix that stops the unnecessary searches?  I would imagine that with a bit of extra code you could really reduce the overhead in opening the file in this circumstance.  Thanks!<br>
<br>Ethan<br>