At the risk of causing an untended war it looks like the only thing that changes was...the newest version of mix emergency.

Maybe you have a corrupt database. I would suggest starting with rebuilding the database and re-analyzing all of your files.

It's more likely to be the program which actually made changes to your files...

I found that some video files which didn't have proper tags got corrupted when I first ran them through Mixed In Key 5. But by the time I came to use that, I'd already moved to 2.3.3 and eliminated the bulk of such files from my library.

Can you see if any of the files in question had XML/OVB metadata files?

I would suggest you try running a few of your pre-MIK files through it again, and see if that makes any difference.

i'd already used the newest (not the beta) mix emergency for awhile previous to the reformat. plus, this seems like something of a tag or rewrite issue.
mix emergency does not do that. i will drop back to the previous ME and see if it continues.

seems it would be more likely an ssl thing. was thinking it could be something like if i corrected a beat count and ssl fktup the rewrite but that never happened before. so why would i now?



there are no xml or ovbs set for these videos that were corrupted.
mixed in key is one of the only things i can think of.
it's the only thing that changes or rewrites something that would cause this.

perian, is there anything there that could cause a problem?

what is so weird is i can play a video tonight but tomorrow suddenly it is corrupted.
here's the other weird thing.
the video shows up in my serato library. i load it, instantly my cue is at the bottom and serato shows it as corrupted. i "control R" to view the file and i can see that quicktime will not play it and it doesn't. so i tried to drag the file back into my library as it's own crate. it will NOT even load it.
basically, serato sees it as a playable video, you can see it in my library, it corrupts and then won't accept it.

going to have to start a help ticket i s'pose.

Perian = no. ME = no. SSL = yes. 80% of the time when a mp4 video shows up corrupted in 2.3.3.x/2.4.x it is the tagging information being outside the specs of what is considered "proper". Possibly going in and deleting the tagging info, then replacing it with new data, could fix the problem. Ive noticed, and Josh mentioned that most of the corrupt mp4 files are old personal mixes, 8th wonder (imagine that)...and other older videos from suspect sites (in which people dont know how to render properly).

I dont use mixed in key, so I cant really say if it could be a part of your problem.

IF, your going to re analyze, I would highly suggest to dive in and use 2.3.3. This way you will be set for future upgrades.

yep, most of these new corruptions are personal edits but not all. thanks millz.
how would i delete all the tag info?

i will jump into 2.3.3 after the weekend.
i thought i had tried it before but now thinking it was the previous version.
i didn't like the retagging or rewriting of vids after they ejected. it caused a delay that messed with my style of mixing. for various reasons a track HAS to be available to mix as soon as it loads.

has anyone gotten any type of delay loading tracks in 2.3.3?

The delay came from Serato copying your old tags and converting the new version. But once they're written it's a done deal. It's obviously best to do this when your not at the club.

yea, i remember and it must have been in 2.3.1.
many people were having problems so we recommend analyzing before hand.
but even after that without even adding a cue or changing anything ssl would occasionally rewrite the file even if it was set to read only.

so it does not do that anymore?
that has been the main and only reason i have not updated.

I've seen it happen on some files, but very rarely. Not to the extreme that you experienced. I've been through it, not fun. Once you analyze them you'll be good.

backup backup backup, yes three of them.

+1.

At least Millz knows his shit ;)

To add:
VSL = no.
Serato Video = no.

So would deleting the tags in something like Tag&Rename work as far his issue here?

Or what about just Demux > Remuxing the files perhaps?

I think the latter would be the last resort. If you have the time, try the other way first.

And it pays off to have a good master video library!

i will try the Tag&Rename route on sunday.
i was going to go to 2.3.3 but will wait and test this. i'd like to narrow this down instead of ignoring it.

i do have 2 master backups.

there are just too many factors i feel here, too many weird things happening.
for instance, my backup was carbon copied a few weeks ago. a vid goes corrupted in my main, so i pull the same one from my back up and it's fine.
and would tagging make the video fine one night and then be corrupted the next?
and this is in 1.9.2...very odd.

Are your external backup drives formatted Mac OS, or as FAT32?

If FAT32, that would be my first suspect...

Mac OS Extended (Journaled)

If you're using 1.9.2, then this is weird indeed. SL 1.9.2. should not alter the files, it was just writing the infamous xml/ovb metadata files. Should not touch the files. So if you were using a different external tool to tag ... then we have a clear suspect.

Well...I definitely remember some issues with some pre-2.2 versions of Scratch Live having "corrupt certain videos on first play" problems. I'd load the track into SL, and the waveform would "eat itself" as the file played, sometimes with weird noises playing. The file would then show as corrupt from then on.

Does that sound like what you're seeing, or is your situation different?

Not sure why duplicating the files would be causing that (or any other kind of playback problem) to be happening suddenly...assuming you did the duplication with CCC, maybe see if results with SuperDuper are any different?

than mixed in key?
the only other thing i have used for tags is itunes, rarely.

for nik39,

Are you using the latest version of mik? they released a fix shortly after the release of mik 5
it probably is not mik but worth upgrading to 5.1

5.0.2.965

i see the 5.1 beta.
and looking at my MIK can not figure out if it has an updater.

yeah I probably meant 5.0.1 or maybe the version you have..All I really remember is when the released 5.0 another update came within a week or two to fix a few bugs (I think that were with mp4's)

i was thinking that each hd is exactly the same, that i used mik on the master a few weeks ago and each backup was copied from that master. so each hd should have corrupted files...but they don't. which is why "i don't get it."
however, i remember now that i did use mik on the master recently and may not have carbon copied it. that would give me mixed results on different hardrives.

so i will go the back ups. throw the same files into mik and see if they come out corrupted.
man, i hope they do or else i will want to throw these HDs out a window.
illogical things do not make sense.

just had this happen to me a few minutes ago with V.I.C. - Twerk It from Smashvision.

I downloaded this file friday from the site. played it @ the club over the weekend with ssl 2.3.3(18) and ME 2.0.2.04... no problems. Played the file in the offline player of ssl several times... no problems. But as soon as i opened up VideoSL and loaded the track again...the file goes corrupt.

There we go. It must be ME 2.0! It's always the things and people we don't know or which are different.

Those damn Mexicans!!

ok this is what i just encountered,

ive totally cleared my corrupt files from my library...

after i loaded the V.I.C - Twerk It file, i started loading other files into the offline player. every single file i loaded, the red filmstrip logo turned into a corrupt logo. I did this for a total of 18 files, all of them turned corrupt and no waveforms appeared.
i disable the vsl plugin, closed ssl and reopened ssl.

the same 18 files were corrupt, so i drag all of them to the Analyze files button, only 7 files turned back to normal, the other 11 remained corrupted.

i loaded a few more tracks into the offline player and they did not turn corrupt.

I've had SSL report corrupt files on me, deleted them in SSL, restarted SSL then reimported and analyzed them only to show normal again. I think there is a quirk that is flagging some files as bad when they really aren't.

^ yeah, i think so too... it seems to only happen to me when i open up vsl, as far as i remember, those are the only times i get "good files gone bad". Now, ill get corrupt files from the get go, but i usually clean those up with mpgstreamclip and they will be fine after that.

How do you do that?....I'm really new to this Video thing going on I do have corrupt files too.

I think there are THREE different kind of corrupt files.
(theres probably more... but this is the ones i see most)

*ones that are just read as corrupt. (they dont even require analyzing... you drop them into ssl and they show corrupt off the bat).. out of the hundreds of corrupt files i found in my switch to 2.3.3. 100% of these were fixed with MpgegStreamclip's "save as"

*ones that ARE actually now corrupted, wont play in any player, and the mp4 file thumbnail is usually an undefined image, these are videos that were fine in 1.9.2 but the sources all go back to 2007... so who knows what was going on when they were ripped.

*Ones that played fine on tuesday, but when you load them into the deck the play point
goes to the END of the track... you cant play it, rewind it, nothing.... I got these in 1.9.2 as well though...

If the corrupted files won't even play in VLC or another player there is also the possibility that the files became corrupted while copying/backing them up. I have had files get messed up numerous times when copying a large amount of tracks from one drive to another.

what backup software are u using?

Right now I use the old-school copy & paste to multiple drives. After I DL new tracks, I save them to 3 different drives - my working drive, and identically configured backup drive, and a music archive drive. I also maintain smaller, Serato configured, emergency sets on the Macbook HD and a 16 gig flash drive.
Manual copying is not too bad once your main catalog is copied over to your backup drive - select all and choose to copy only new tracks (don't replace). I will also be setting up a backup program soon as I get the time and some extra drives. My workstation currently has 9 drives connected, none smaller than 500 gig...

You tried carbon copy cloner for mac? it's got an error detection tool that can be ran during your backup which will notify you of errors in files (takes a lil longer to back up with this enabled, but it does work.) ive caught a few corrupt files this way.

oh man, what is that error detection tool?

if you open the latest version of CCC, select your source disk then select the destination drive. click on the "customize these settings..." button. go to the bottom and click on the "Advanced Settings..." button. Check the box that says "Calculate a checksum for every compared file". That will enable the detailed cross check of your master and clone drives.

from the CCC website:

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. CCC then uses these MD5 checksums to determine if a file should be copied. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination. This is a reliable method of verifying that the files that have been copied to your destination volume actually match the contents of the files on the source volume.

Media failures occur on nearly every hard drive at some point in the hard drive's life. These errors affect your data randomly, and go undetected until an attempt is made to read data from the failed sector of media. If a file has not been modified since a previous (successful) backup, CCC will not ordinarily attempt to read every byte of that file's content. As a result, it is possible for a corrupted file to go unnoticed on your source or destination volume. Obviously this is a concern if the file is important, and one day you actually need to recover the contents of that file.

Frequent use of the checksum calculation option may be a burden upon your productivity. We do recommend, though, that you add this option to a weekly or monthly backup regimen to verify the integroty of your backup.

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version.

so here is the most fktup thing about this;

1) in the offline player of ssl there is still the lighting bolt for corrupted file. however, the mp4 loads and plays. it will even display the video.
2) if you go to the file to the file on the hd it will not play. it has that wonky qt emblem and it's not in a format for quicktime.
3) if i plug in the 57 the file will no longer play in ssl.

so what is the difference between the offline ssl player and online?
why will it play?



the file is bad either way and will be deleted but this is weird.

Ok So I figured something out about corrupted files.. I downloaded the files all over again and go the same results. So I moved them into a seprate folder and added them back into the correct folder and they worked just fine. So I figured if you remove the files and move them to a different folder they wouldn't show up corrupt

This works for me at times... sometimes when I add a bunch of files and analyze them and immediately try to load them into the player it shows corrupt. I then have to remove them, exit out, readd them and reanalyze. Then I exit out one last time and when I run SSL again they load with no errors/warnings etc.

i believe this has something to do with a combination Carbon Copy Cloner and probably SSL
don't know how or why it does it.

everything will be fine.
i use CCC and the first time i load and play a video in ssl and nothing strange happens.
the next time i load and play the video it's corrupted.

i went weeks without a problem, used CCC again and bad vids are popping up.
i am going to start a help ticket for ssl. it's odd that the vid plays in the offline player.

well, i figured out the issue...just not how to fix it.


it's in the writing of tags.
1) I load and play a video with either the 57 or sl1 plugged in.
2) i change a tag. for instance write the artist name in.
3) load another video
4) load the video from step 2 and it is corrupted.

it only happens on videos and i have already purposefully corrupted enough of them.
also, without messing more up i think it is only happening in the "artist" tag. changing comments seems unaffected.

and looking back at help requests, i did test 2.3.0 and possibly 2.3.3.
since i have about 15-20 drives it is highly probable that this was a drive used for that testing.

is it possible to strip all the "whatevs" analyzing of 2.3+ from my vids?

i am thinking maybe because these may have been analyzed in a 2.3 and i am using them in 1.9.2 it's messing with the tag writing.
could be, maybe?

Do you think that using iTunes for all of your tagging would solve this issue?

probably, since this is an ssl issue.
however, i do tag rewriting on the fly during sets, just little notes to myself.
that can not be resolved with itunes or another any other tagger.
if i determine it is only within the artist and track section it can be side tracked i suppose.

i know they aren't doing any fixes to 192 but perhaps this can lead to what causes corruptions in other versions.


but in the mean time i'd like to know if it's possible to rework these vids if they are from 2.3+

u should download the 2.4.2 public beta and test with that.

but then mix emergency would not work :(

or is that some kind of sick Burgh joke??

to test issues with ssl, you dont need me to actually work, see what im sayin :)

oooh, yes sir.

thanks.

oh, but what would i be testing exactly?
any suggestions on what and how i should test it would be great.

i'd start off with, see if this occurs there too.
analyze some files and check them in 192.
but that's all i can think of.

imo, if you are having library issues, I would down the latest beta. Copy your library files to a backup folder, install the latest beta, delete all your crates (making sure you have the backup to replace after testing). Make new crates, add new files, analyze them with the most recent build. See what happens then....

This is simply a suggestion. I get nervous anytime I delete my crates, in fear of them not coming bakc after I replace the testing folders with the ones I copied.

In 2.3.3.18, and the newest public beta, I am not having the library issues you are having. The few corrupt files that I do have are mp4 files that I have either gotten from another editor not using the proper specs, or 8th wonder files. I have been steady replacing any old/shit quality vidz with those found on www.vj-pro.com and am enjoying a higher quality, overall better file than those from other sites.

I'm following the same process myself. Biggest hurdle right now is taking the time to remove the crappier non-corrupt tracks I've updated from my library in a timely manner.. I really don't need 3 copies of Ready For The World - Love You Down at my finger tips..........

ok. will start that after tonight's gig or when Anthony replies to my help ticket.
deletig crates does not bother, soooo used to it.
i used to play 4 different types of gigs each week and had to constantly until i learned to create various types of backups.
plus, my crates mirror my hd and the ones that aren't mirrored are in itunes playlists.



btw the issue i am having with occurs with vids from all sources.
this never happened before and if it was an issue normally inherent in 192 it would have come up with many other people as well.
i can't help but think it has something to do with testing 2.3

wow...crazy typos.

btw my help ticket is here.
serato.com

I think what Millz mentioned in the other thread might be good to try too.

and i remember around namm time speaking to AnthonyS on the phone and him saying something like "analyzed videos in 2.3 are not reverse compatible with previous versions."
but i could not narrow him down to exactly what that meant or what it would do.


i am going to consider all the suggestions and go with the least intrusive until Anthony replies.
i'd hate to analyze and fkup vids even more. lol

Well if you have the extra room somewhere take the last group that were corrupted, strip those down as a test base.. I know I am rooting out the stupid PO videos with the track tags in them that freaks out SSL and making sure I have those on my BACKUP set so I never have to traumatize myself with that again.

got a reply from AnthonyS....

Hi tomatoslice,

I have tested those files in Scratch Live 1.9.2 and managed to re-produce the behavior that you detail above with the original files.

I'm not certain on the cause of this one but when testing in Scratch Live 2.3.3 and latter I don't have any issues with those files.

I then used MPEGStreamclip's 'Save As' feature to rebuild the .mp4 container file and header on those two files.

Opened Scratch Live 1.9.2.
Analyzed the files in 1.9.2 and changed the artist and year tags.
Reloaded the tracks and reopened Scratch Live.
Tags all good and NO Corruption.

I would assume that somewhere along the line .mp4 header information has become corrupt.

If you are not interested in upgrading to Scratch Live 2.3.3 then this is my suggested workaround for you to deal with corrupt files like this.

now what i would like to know is...

AnthonyS was using MY files.
i'd like to know if it is MY files...can someone using 192 create a corruption with their own file?