I'm glad I'm not the only one that worries about sample accuracy!
There are issues with Live 8's lack of alignment of automation and song position information to plugins which I want fixed as much as everyone else here, but there is another issue which is not very well understood, and more general that applies to all DAW users.
There is something called a "two path polyphase IIR filter" as outlined in the paper "The Design of Arbitrary-Band Multi-Path Polyphase IIR Filters" by Dr Artur Krukowski and Dr Izzet Kale, which is commonly used for oversampling. It's used in Live 8's EQ 8 in HQ mode and it's used by loads of people in the audio industry since it's low cpu and has a very steep filter rolloff. So what's the down side? In DSP there is always a tradeoff, it's this case it's the non-linear phase response. This will delay your incoming signal by somewhere from 2.x samples to 4.x samples (depending on the steepness of the design) at DC that with frequency in a non-linear way.
Ok, so what does that mean? This means if one of these polyphase IIR oversampling filters is in your signal path that you have a fractional (sub-sample) delay unit processing your entire signal, and the fraction of a sample it delays your signal increases with frequency, so there is absolutely no way you can compensate for this, other than to run ALL your other tracks through the same filter to delay them by the same amount. But hang on, it's not that easy, since if you chain three plugins, each which uses their own design of an IIR polyphase oversampling filter, then you need to reconstruct the exact same "clean" version by passing all your other audio tracks through exactly the same total chain, but without doing any processing on the signal. That is just to align two tracks together. Have different plugin chains on different tracks and it becomes impossible to correct for.
I repeat, this issue is not the sole problem of Live 8's oversampling as used in the EQ8 HQ mode, it's everywhere and it's an issue in all DAWS - but many developers keep quiet about using it since the polyphase IIR solution is cheaper in cpu and does a really good job if you don't care about your phase going out of whack with other tracks. You basically have to verify this yourself by putting a single sample spike through a plugin and see what it looks like once it's processed since developers can't even declare the delay to a host since each frequency has it's own fractional delay and hosts only take a single integer as the delay to compensate (which is fine, that should be enough!)
There is a solution, and that is to use linear phase FIR oversampling filters. Ok so what's the tradeoff for this fix? Slightly more cpu usage and more latency, but this time the latency is constant and can be corrected for by the phase so the crack of your transients all stay put and don't turn into limp plops when they phase with other parts of your track.
So in summary the polyphase IIR oversamplers do a really good job for the amount of cpu they use, and they introduce minimal latency into the signal path, but the latency they do introduce is non-linear and can't be corrected for easily, and so can cause phase issues. The FIR alternative uses more cpu and latency, but the latency is constant and can be corrected for. So either way it's a bummer.
A much better solution is to run your entire project at 88.2 khz or 96 khz, then you don't need to oversample in individual plugins, and all your EQ shapes are very analog like in shape and phase, and your aliasing is reduced across the board so all your mixes are clearer and tighter. If the oversampling can be bypassed in your plugins (which I allow in mine by not all developers support) then there is no extra latency introduced so nothing needs correcting for. The cost here is increased CPU usage across the board as well, with every single plugin taking twice as much cpu.
There are issues with Live 8's lack of alignment of automation and song position information to plugins which I want fixed as much as everyone else here, but there is another issue which is not very well understood, and more general that applies to all DAW users.
There is something called a "two path polyphase IIR filter" as outlined in the paper "The Design of Arbitrary-Band Multi-Path Polyphase IIR Filters" by Dr Artur Krukowski and Dr Izzet Kale, which is commonly used for oversampling. It's used in Live 8's EQ 8 in HQ mode and it's used by loads of people in the audio industry since it's low cpu and has a very steep filter rolloff. So what's the down side? In DSP there is always a tradeoff, it's this case it's the non-linear phase response. This will delay your incoming signal by somewhere from 2.x samples to 4.x samples (depending on the steepness of the design) at DC that with frequency in a non-linear way.
Ok, so what does that mean? This means if one of these polyphase IIR oversampling filters is in your signal path that you have a fractional (sub-sample) delay unit processing your entire signal, and the fraction of a sample it delays your signal increases with frequency, so there is absolutely no way you can compensate for this, other than to run ALL your other tracks through the same filter to delay them by the same amount. But hang on, it's not that easy, since if you chain three plugins, each which uses their own design of an IIR polyphase oversampling filter, then you need to reconstruct the exact same "clean" version by passing all your other audio tracks through exactly the same total chain, but without doing any processing on the signal. That is just to align two tracks together. Have different plugin chains on different tracks and it becomes impossible to correct for.
I repeat, this issue is not the sole problem of Live 8's oversampling as used in the EQ8 HQ mode, it's everywhere and it's an issue in all DAWS - but many developers keep quiet about using it since the polyphase IIR solution is cheaper in cpu and does a really good job if you don't care about your phase going out of whack with other tracks. You basically have to verify this yourself by putting a single sample spike through a plugin and see what it looks like once it's processed since developers can't even declare the delay to a host since each frequency has it's own fractional delay and hosts only take a single integer as the delay to compensate (which is fine, that should be enough!)
There is a solution, and that is to use linear phase FIR oversampling filters. Ok so what's the tradeoff for this fix? Slightly more cpu usage and more latency, but this time the latency is constant and can be corrected for by the phase so the crack of your transients all stay put and don't turn into limp plops when they phase with other parts of your track.
So in summary the polyphase IIR oversamplers do a really good job for the amount of cpu they use, and they introduce minimal latency into the signal path, but the latency they do introduce is non-linear and can't be corrected for easily, and so can cause phase issues. The FIR alternative uses more cpu and latency, but the latency is constant and can be corrected for. So either way it's a bummer.
A much better solution is to run your entire project at 88.2 khz or 96 khz, then you don't need to oversample in individual plugins, and all your EQ shapes are very analog like in shape and phase, and your aliasing is reduced across the board so all your mixes are clearer and tighter. If the oversampling can be bypassed in your plugins (which I allow in mine by not all developers support) then there is no extra latency introduced so nothing needs correcting for. The cost here is increased CPU usage across the board as well, with every single plugin taking twice as much cpu.
мой перевод (сори за транслит):
есть такой тип фильтра именуемый "two path polyphase IIR filter" как описано в труде "The Design of Arbitrary-Band Multi-Path Polyphase IIR Filters" by Dr Artur Krukowski and Dr Izzet Kale который часто используется для оверсамплинга. он используетса в eq8 в режиме hq, а так же множеством людей в аудио индустрии так как имеет низкую нагрузку на cpu и очень крутой спад фильтра - steep filter rolloff. так какие же у него минусы? в dsp всегда есть какой то компромис. в данном случае это non-linear phase response. Эта привнесёт задержку в поступаюший сигнал ~ от 2.х самплов до 4.х самплов в зависимости от крутизны дизайна - steepness of the design
так что это всё значит? когда вы используете этот тип фильтра - polyphase IIR oversampling filter - обрабативая сигнал он привносит частичную задержку - fractional (sub-sample) delay - в весь обравативаемий сигнал и эта частичная задержка увиличивается пропорционально частоте, поэтому нету способа ее компенсировать для daw, но можно пропустить все ваши треки через тот же фильтр добавив к ним то же время задержки... Однако есть одна загвоздка в этом методе, используя цепочку разных плагинов с разным дизайном IIR polyphase oversampling filter-а, то нужно будет прогонять все ваши треки через эту цепочку, но не обрабатывая их а только для того чтобы выровнить/компенсировать задержку.
Эта проблема присуща любой daw но разработчики молчат так как polyphase IIR вариант имеет низкую нагрузку на cpu и хорошо справлается со своей задачей, если вы не замарачиваетесь о разъезжающейся фазе между вашими треками.
есть решение проблемы - использовать linear phase FIR oversampling filters. а какой будет с ними компромис? большая нагрузка cpu и больше задержки, но в этом случае задержка константа и может быть компенсирована.
подводя итог polyphase IIR oversamplers делают хорошую работу, но вносят фазовые искожения. их альтернатива FIR использует больше cpu но задержка может быть компенсирована.
Намного более предпочтительный выход из положения - установить весь ваш проэкт в 88.2 или 96 kHz тогда нет необходимости делать оверсамплиг индивидуальным плагинам и все кривые eq более подобны аналоговым по форме и по фазе и алиасинг уменьшается на всём миксе, делая его более чистым и собранным. если ваши плагины позволяют отключить оверсамплинг тогда никакой экстра задержки не привносится и нет необходимости ее компенсировать. естественно это требует значительно большей нагрузки на cpu.
Последнее редактирование:
unk:
