I used to have a lot of files encoded as h.264 with Apple Lossless audio, but I've recently moved to h.264/AAC as I found my system did struggle a bit sometimes.

Basically you're asking your system to decode a LOT of bits at once, like encoding your videos at a very high bitrate.

I find that encoding out of FCP with 320k AAC is pretty damn close in quality if your starting quality is good in the first place. And I found my video performance to be smoother.

Maybe try Apple Lossless on a few videos first, if you've got a kick-ass machine. Anything less than a 2011 MBP I would suggest you stick to AAC audio.

Hmmm. I need to find a workaround pretty pronto as have a massive massive show next week. Another Video SL friend of mine who's very good with these things feels I should create much more space on my HD. I currently have 20GB of a 500GB drive free and optimised it SHOULD have 50% free apparently. I really don't wanna have to redo 30 odd videos to 320k AAC unless its absolutely essential.

My average file sizes are 250MB. These are for tracks that are often 6mins long. Does that sound too large?

250mb is pretty big, yeah.

A .wav file will usually have a bitrate of 1411kps, that's more than 3 times the bitrate of a 320kps aac file.

That's a lot of data to push when you add on 3000-odd kps for the video portion of the file. What video bitrate are you using?

My suggestion as a short term fix would be to export the audio from your videos in QT, convert them to aac or mp3, and then link those audio files to your existing videos in SL.

That way VSL isn't having to decode such large amounts of audio data.

You could do with a bit more space on your HD, for sure.

One other suggestion... MixEmergency. Most users find that ME is less demanding on their systems, myself included.

You should download the demo from Inklen and try your files with that.

That is a very good little workaround and relatively achievable in a short space of time. I shall try that if all else fails.

I can't remember what bitrate of the files are offhand, I will check when I get home.

I am going to have a drive clean up pronto.

Use Mixed Emergency instead of Video SL?

A LARGE amount of Mac-using Video DJs you'll see posting in the VSL general discussion area have made the switch to ME a long time ago.

Features-wise VSL has fallen a long way behind ME.

We're all hoping for a new version of VSL at NAMM, but it's gonna have to be pretty damn special for me to switch back from ME, let's put it like that.

I think I'll be staying with Video SL unless it becomes unreliable. At the moment, its OK, two total system freezes since last July isn't bad. I DJ with ScratchLive so it all seems to fit fine with me.

Fair enough, I'm not here to sell you on ME if you're happy with VSL. It's just another option if you need it.

Let us know how you get on with those other ideas.

I should point out the Video freezes when I've had these two crashes. Audio carries on playing and you can still manipulate it with the control vinyl. Would that not suggest a video problem not an audio one?

here's the crash report. I hope its the right part:

Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: NVDA(OpenGL): Channel exception! exception type = 0xd = GR: SW Notify Error
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 0000006e
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00200000 00005039 00000474 00000002
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 0000047c 00000310 51945000 0000000f
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00000000 00000000 00000043
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00000002 00000000
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: NVDA(OpenGL): Channel exception! exception type = 0xd = GR: SW Notify Error
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 0000006e
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00200000 00008597 00000474 00000010
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 0000047e 00001408 00000001 0000000f
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00000000 00000000 00000603
Jan 4 19:38:28 Tom-Millers-MacBook-Pro kernel[0]: 00000010 00000000
Jan 4 19:39:41 localhost kernel[0]: npvhash=4095
Jan 4 19:39:41 localhost kernel[0]: PAE enabled
Jan 4 19:39:41 localhost kernel[0]: 64 bit mode enabled
Jan 4 19:39:41 localhost kernel[0]: Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386
Jan 4 19:39:41 localhost kernel[0]: vm_page_bootstrap: 981422 free pages and 26194 wired pages
Jan 4 19:39:41 localhost kernel[0]: standard timeslicing quantum is 10000 us
Jan 4 19:39:41 localhost kernel[0]: mig_table_max_displ = 73
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=2 LocalApicId=1 Enabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=3 LocalApicId=4 Enabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=4 LocalApicId=5 Enabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=5 LocalApicId=0 Disabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=6 LocalApicId=0 Disabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=7 LocalApicId=0 Disabled
Jan 4 19:39:41 localhost kernel[0]: AppleACPICPU: ProcessorId=8 LocalApicId=0 Disabled
Jan 4 19:39:41 localhost kernel[0]: calling mpo_policy_init for TMSafetyNet
Jan 4 19:39:41 localhost kernel[0]: Security policy loaded: Safety net for Time Machine (TMSafetyNet)
Jan 4 19:39:41 localhost kernel[0]: calling mpo_policy_init for Quarantine
Jan 4 19:39:41 localhost kernel[0]: Security policy loaded: Quarantine policy (Quarantine)
Jan 4 19:39:41 localhost kernel[0]: calling mpo_policy_init for Sandbox
Jan 4 19:39:41 localhost kernel[0]: Security policy loaded: Seatbelt sandbox policy (Sandbox)
Jan 4 19:39:41 localhost kernel[0]: Copyright (c) 1982, 1986, 1989, 1991, 1993
Jan 4 19:39:41 localhost kernel[0]: The Regents of the University of California. All rights reserved.
Jan 4 19:39:41 localhost kernel[0]: MAC Framework successfully initialized
Jan 4 19:39:41 localhost kernel[0]: using 16384 buffer headers and 4096 cluster IO buffer headers
Jan 4 19:39:41 localhost kernel[0]: IOAPIC: Version 0x20 Vectors 64:87

My Mac's overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro6,2
Processor Name: Intel Core i5
Processor Speed: 2.4 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache (per core): 256 KB
L3 Cache: 3 MB
Memory: 4 GB
Processor Interconnect Speed: 4.8 GT/s
Boot ROM Version: MBP61.0057.B0C

Intel HD Graphics:
Chipset Model: Intel HD Graphics
Type: GPU
Bus: Built-In
VRAM (Total): 288 MB
Vendor: Intel (0x8086)
Device ID: 0x0046
Revision ID: 0x0018
gMux Version: 1.9.21

NVIDIA GeForce GT 330M:

Chipset Model: NVIDIA GeForce GT 330M
Type: GPU
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 256 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0a29
Revision ID: 0x00a2
ROM Revision: 3560
gMux Version: 1.9.21

Hey tomcentral,

Have you installed Perian? If not can you install this from here:

perian.org

Can you also let me know what your output settings in Video-SL are set to?

Sam.

Here you go. Let me know what you think of those. Thanks a lot!

I've got Perian installed btw.

Can you try setting your output quality to medium rather than high and let me know if you get the same issues?

Will do. Thanks.

No crash after a after a 1 hour session. Having said that the machine's only crashed fully twice since starting on Video SL last July. I adjusted the output quality to Medium. Certainly the machine seems to be coping better and the graphics don't stick at all which they are known to do infrequently. Before this I also peeled off 150GB from my internal HD.

Did the crash report provide any clues?

Sorry Tom, there wasn't anything that I could read from that crash report as to why this happened. It looks like your processor was getting overloaded when the quality was set to high which may have been the cause if this spiked as this quality setting is very CPU intensive. If you are not playing HD quality video's than you shouldn't have any quality issues playing your video's at medium :)

Cheers,

Sam.

having the audio as .wav is actually easier on the CPU, because no decoding needs to be done! With mp3 or aac, the audio would first need to be decoded by the CPU, and then streamed to coreaudio. Wavs are streamed directly from the HD. So having the sound as wav should save CPU resources to some extent.

cheers,

Bob

OK, so approx 40 mins into the first mix since I made all the adjustments discussed in this thread and I got a whole heap of USB audio dropouts. Red flashing USB circle in Serato followed by an ugly total system freeze. The playing deck stayed spinning complete restart required. Couldn't quit out of Serato. I understand that I need to move the buffer slider to the right to address this issue. After reboot, Video SL worked fine for another half hour.

One thing I DID notice whilst looking in my Mac's Activity Monitor is that I have had Little Snitch running all along as well as Dropbox. Might these two programs have caused earlier problems and/or this current one?

This is a little frustrating that its a different type of crash now. Any ideas?

don't know about little snitch, but dropbox will regularly try to contact the server to check for file updates. Might tip your machine over the edge if it's already being pushed hard. Definitely turn it off while using Video SL!

Thanks Krabbz, do you think that might have been causing the USB dropouts? I starting getting them with two tunes in the mix with FX running in Video SL so pretty much the machine is being asked to do a lot at that particular moment in time. I'm assuming that if something in the background decides to try and connect to a server at the moment it would bring Serato down.

Any idea how I would get an accurate crash report after a total system freeze? I have to hold the power button down to get the machine off and on again so regular crash reports aren't possible.

PS: I got a massive, massive gig on Saturday: thousands of people, I need to resolve this pronto :)

I would disable little snitch also, this could be causing conflicts. Unfortunately with freezes, there are no reports generated that are able to be translated. This is only possible with a complete application crash.

Can you upload a couple of the files you are getting crashes using? I'll need to try and reproduce this here.

Sam.

Hi Sam, thanks for getting back to me. The files are hundreds of MB is it still advisable to upload. Could you give me an idea of recommended bit rates? I've got some here that are over 100,000 and thinking maybe this is the problem....

It sounds like these are encoded in a way thats not recommended for use with Video-SL if the files are hundreds of MB. These sound like very very large files and this is probably causing your problems. Are you able to try encoding a video using our handbrake preset? You can find this and instructions on how to do this here:

serato.com

Let me know how you get on.

Sam.

Hi Sam, you're right these files are way too big. We've been encoding straight out of Ableton and Final Cut Pro. I just ran a quick test re-encoding a larger file and the new file size and bit rate is much smaller. But I wonder if there is a way to output the audio at WAV quality as these presets are for 320kbps which we'd like to improve on if possible.

Thanks for your help on this!

t

Are you able to change the audio codec to AAC in handbrake? This is lossless too and should be better quality than 320kbps mp3.

I got AAC (Core Audio); AAC (FAAC); mp3(lame); AC3 as my options. With the AAC (Core Audio) which is giving me some much tidier file sizes and bit rates than my other files. However, the audio bitrate is still cited as 320kbps. You're saying that AAC 320kbps is superior to mp3 320kbps?

Thanks again.

Sorry, I was thinking for a second that AAC was lossless for some reason. My bad.

I'm not sure that you can change the audio codec to anything else using Handbrake sorry. There may be other encoding software packages that allow this but I wouldn't know for sure.

Maybe some other users may know though :) I'll move this to the general discussion area and they can chime in too.

Sam.

Any ideas Video SL users? I've got a load of .mov files that ideally need to be re-encoded ensuring that the overall bitrate stays comparable to the Serato recommended settings put maintains a WAV quality audio.

You could try my old set-up and test a couple with Apple Lossless audio instead.

Your old set up?

My first post above, dude...

Right gotcha thanks phatbob. Will bear that in mind. Most of our videos have been encoded out of Ableton with Lossless Audio creating around total bitrates of 10,000. I think I've isolated the problem down to one file that unexplicably encoded to 14GB and I didn't realise until the machine had crashed. I've resolved to stay with Lossless audio as long as the files don't get much bigger and if I have another crash I'll switching to the Handbrake presets as discussed about.

Thanks for your help dude.