Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jherbert]

The analyze audio function hangs badly when it comes upon corrupted files instead of skipping these.

In effect this makes it impossible to go through a large music collection, because you never know when this might happen. The only cure I found is to stop the analysis, make a best guess which file caused the trouble and then try again on the rest.

Stopping the analysis crashes MC17 in most cases, which does not make things better.

Two wishes / suggestions:

- Implement some kind of error handling, so that bad files are skipped in reasonable time instead of looping forever
- flag these bad files as bad and make that searchable

As an alternative I would like to see a function that checks for bad files.

I have several aac files that are (went?) bad for unknown reasons. Upon playing they stop producing any sound and go into endless buffering.

[leezer3]

Obviously, it shouldn't do that 
I've never managed to crash audio analysis, so your files must be special!
If you can upload a copy of one of these corrupt files somewhere, with any luck one of the developers should be able to stop the crashing I'd hope.

-Leezer-

[Matt]

Please send a sample file that causes a problem to matt at jriver dot com.

Thanks.

[Matt]

Thanks for the file.

Like you said, it looks like the file is corrupt.

The decoder keeps working through the corrupt frames, and does eventually finish.  It just gets really slow once it gets to the corrupt frames.

There's no reason it should have to be so slow though, it's just a side-effect of how it reads when that happens.

I'll try to get it fixed for a coming build.

[jherbert]

Thank you, this is really appreciated. I wonder if there is an equivalent to foobar's "verify integrity" plugin that may be used with MC17. I have used this now to verify my library, but the workflow leaves a lot to be desired.