Mixing tracks in FLAC

That is unrelated to the file-type and encoding.

Ardour does not read raw audio data to show the waveform when zooming or scrolling. Files are analyzed once and dedicated peak-files are used after that.

Also note that all processing inside Ardour uses floating point (regardless of the file type).

1 Like

Try pitch shifting a flac file in windows then try a wav session, the flac takes longer for me. And zooming in and out of waveform on flac it’s stuttery but wav it’s smoother

Maybe it’s a bug For me not sure

Yes, I keep forgetting to file a bug report, where the ‘silent’ portions take longer to render. The waveform zooming stutter is also only on ‘silent’ portions.

Try turning on the ‘Use DC Bias to protect against denormals’, and experiment with ‘FlushtoZero’ and the other options. This helped reduce render times for audio with long silent portions.

I also make sure to strip silence all my audio before starting work, so that the zoom in-out stutter on waveform rendering is rare.

Thanks for the insight.

But when zooming beyond a point, the flac files do freeze the ui for a few milliseconds on ‘silent’ sections. I am guessing, the peaks are used only for larger waveform previews. And beyond a certain magnification they are computed from raw audio.

Ya that’s what happens.

Of course FLAC will take (relatively) longer! For obvious reasons, a DAW like Ardour needs the raw audio samples for its internal use and processing. While an uncompressed audio file (such may be a .wav) needs only to be read to get such samples, an encoded file such as FLAC needs to be decoded first. Doing so obviously requires some extra memory and CPU cycles (that is, some time).

Nowadays, on a decent computer, the overhead caused by FLAC decoding should be negligible. But if you’re using an old or underrated machine and/or some very busy sessions (with plenty of tracks and/or “heavy” plugins) so that the system is already close to its limits, then the extra load caused by FLAC decoding may become noticeable.

It’s not a bug, or a problem per se. It’s simply how things works. Whether it may become a problem or not depends on the specific context.

I understand, it’s just when I use studio one i use flac for a project I’m doing, and it works great. I don’t notice any difference but I save lots of space, I only notice a bit higher disk usage when I jump around the time line quickly etc

that can be an indication that studio one is using some sort of caching mechanism. May be, rather than decoding FLAC on the fly as needed, as possibly does Ardour, perhaps it decodes chunks of data in advance and caches (saves) them uncompressed on temporary disk files. Of course that will still require some time, but the extra load may be shifted in time, which in some situations may provide some advantages in itself. Better yet, in case of frequent/repeated access to the same chunk of data, the overhead can be completely eliminated when hitting the cache. Thus, at the cost of higher (temporary) disk usage, at least in some cases that strategy may pay off and provide a smoother experience, like you have noticed.

N.B.: all of that is just an educated guesswork. I do not know how Ardour (let alone Studio One, which is not OSS) actually handles that. Possibly both of them do use a cache, with different sizes and strategies. Or maybe neither one does, and there’s some other reason for what you’ve experienced. Or whatever… :sweat_smile:

Ardour only caches in RAM not on disk. – but if the system has enough RAM Linux (the kernel) does an amazing job at keeping a disk-cache.

32bit wav can be memory mapped with very little overhead and one can directly locate with sample-accuracy to a give byte. Seeking in FLAC usually involves rewinding a bit, and decoding until a given sample. So yes, scroll at high zoom level can take longer.

1 Like

and just to clarify something in Robin’s reply: Ardour builds “peak files” for every audio file in a session, which are used to draw waveforms when zoomed out beyond a certain point. We only need to read the original audio files when you zoom in beyond a certain point. So FLAC/WAV/etc will make no difference to scrolling/drawing speed if you are zoomed out, but can make a difference if zoomed in.

2 Likes

I guess the zoom can’t be fixed in ardour. I decided to use flac again based on storage issues. A fairly big protect I’m mixing is around 30GB for all songs. I guess I could reduce it about getting rid of tracks I don’t need in each song but that is not fully decided yet and how with flac 0 my space is like just over 3GB. I have a Mac with 256 non removable storage and it’s not always ideal for me to have usb drives plugged in all the time, especially if I was using a laptop. But I may just use wav if I’m just working on 1 song only and maybe flac for larger projects.

Performance is good on flac in other daws, ardour has some hiccups but maybe I’ll just use wav in ardour.

Storage space is cheap but apple ssd is not lol, but ssds in general are not cheap, unless I buy a cheap grade external ssd but I try to get quality parts if that’s the case

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.