If you re analyze these files - does it fix them?

Hover your mouse over the corrupt icon - what does it say is wrong with the file?

Can you upload one to this thread pls?

Ding! Re-analyzing does the trick. Thanks!

Some of the WAVs are not fixed by re-analyzing them.

Almost all of the WAVs are from Trackitdown.net. They've been in my library for years, and never had issues. It's not all the Trackitdown.net WAVs I have, just a a few. Almost all of them are tracks I bought and added in 2007/2008.

Once I download a track, I toss it into iTunes and edits the tags. Scratch Live only imports my iTunes - I never add stuff manually. Been doing things this way from the first day I got SSL, back in 2006. Never had this issue until very recently, afaik.

Here's the start and end of one of the WAVs, and the full WAV file (zipped).

Here is the original WAV from a backup. This is the original, virgin file as it was downloaded. Never modified, never put through iTunes or Scratch Live or anything else whatsoever. Just sitting on a backup hard drive all these years.

Looks like the footer is appended to by Scratch Live. The RIFF is different, too. Not sure what changed that. Doing more research.

Riffpad thinks there is "extra junk" at the end of the file, but I am assuming that's the Scratch Live GEOB and tags that are supposed to be there.

On a different file, I get "This file seems to be corrupt for a RIFF" and this output (see image for "Get Down").

Most of the offending WAVs seem to just have the SSL stuff tacked on at the end, but a few are like that Tiesto track I just screenshotted. No clue what's going on there.

"Get Down" is a fairly recent track - only a year old - and it's from Beatport instead of Trackitdown.

"Uh Oh" is also relatively newer. I purchased it around January 2011 from Trackitdown.

I removed all the offending WAVs from iTunes, added the originals from a backup (you have all your music backed up on external storage that you keep in a safe location and never touch, and also on an external drive that you take to gigs... right?), tagged them up in iTunes, and then had Scratch Live "Rescan ID3 Tags" and "Analyze Files".

All of the files show up as normal when I first open Scratch Live, but if I analyze them, they all display "Corrupt File: This WAV is incomplete".

Unchecked "read iTunes library", deleted the files' entries from Scratch Live, and restarted Scratch Live. Rechecked "read iTunes library" and restarted. The files appear whole at first glance. Dragging one onto a deck builds the waveform, detects BPM, etc. - file doesn't appear to be broken, and there's no "broken iTunes" symbol next to it. "Analyze files" = they're all broken, even the one that wasn't broken when I played it.

Next step: deleting the files from Scratch Live and then really deleting them from iTunes and the hard drive again - and then re-encoding them all in Audacity and adding them to iTunes and Scratch Live again.

Running all the offending WAVs through Audacity to re-encode them seems to have done the trick. Analyzing them doesn't cause them to show up as broken, no errors come up, waveforms are built and stick, and it looks like cues work as well. SHAZBOT!

TL;DR: re-encoding fixes the files, but I'd like to know *why* this happened.

Files can be marked corrupt for various reasons. Hovering your Mouse over the Broken CD Icon will tell you what Scratch Live doesnt like about the file.

Newer versions of Scratch Live will detect corrupf iles better, therefore you may see more corrupt files come up with newer versions.

Regardless, re encoding the file can fix the corruption if the file actually plays well. Seems like you found this trick.

You should be fine from here.

Hovering reveals "Corrupt File: This WAV is incomplete". Same error on all the offending WAVs.

The weird thing is, not only did I never notice this until 2.4, but I never had any real issues with SSL until right after I got a Sixty Two and upgraded to 2.4. Now Scratch Live often has CPU spikes if I run it without the hardware, and I was told that this was because of the corrupt files... but if so, why didn't I ever have issues in older versions?

The re-encoding fixes the WAVs, so now I'm good.

But I'm just wondering why all this suddenly came up in 2.4 - not just that Scratch Live detected these errors, but that it started acting wonky, presumably because of the corrupt files.

It's fixed, but I'm wondering what the root cause is/was. I know you guys probably have a mountain of questions to look into, and this isn't a huge deal since I can just re-encode files, but if you could check out the WAVs I uploaded and shed some light on what makes them broken, that would definitely help. Maybe there's something in the original files that I could look for in the future, before I end up with a bunch of files that need to be re-encoded, re-tagged, re-cued, etc. Thanks!

Older versions didnt consider those files corrupt.

2.4 requires for all files to be re analyzed. This way it can adapt all the new tag and waveform changes. It will act wierd if the files are not re analyzed in 2.4. So go ahead and do so.


When a file is considered incomplete it just means Scratch Live feels the file has been cut off. Typically this happens with mixes that are tracked out. Often - re encoding can fix these files. I dont think you have much to worry about.