Fabfilter or IZotope?

[MXJIA]

Is there a benefit to mixing/mastering at 192khz? If the end listener can't tell the difference on 44.1/48 sample rates and your CPU gets bogged down, it might be better to compromise and stick to 96

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

I’m going to do more research but definitely I will refrain from using linear phase on my Fruity/Fabfilter EQs when it doesn’t seem necessary.

Only ever use linear phase if you absolutely don't want to disturb phase. So for mastering it can make sense to use linear phase for the LP, HP filtering and delicate bass work, in the sub 0-250hz range.

But, any other eq than this, linear phase is absolutely not necessary and can even sound worse than regular ol zero latency. Only will extreme filtering and cuts/boost change phase in audible ways - except one area which is the bass range. I do prefer proq3 in lin phase mode whenever I eq either sub 200 hz on a master, or when processing a kickdrum. For the bassline, zero latency hp filtering is actually beneficial, cause you can use it as you would an all pass filter, meaning you can shift or even rotate phase to fit better with the kickdrum.

And for mastering using non linear phase for boosts or cut from 250hz and up, can actually sound better.

So, to make it short, I only ever use lin phase for hp and LP filters in mastering, delicate eq work in bass area in mastering, and HP a kickdrum, which I rarely ever do.
So pretty much only two reasons to use linear phase IMHO. But never forget the golden rule, if it sounds good you're doing it right.
There are some technicals that don't change though, and are not subjective.
Oh and pro-mb simply sounds better all the time, in linear phase mode. At least to my ears.

Ahh okay, think I’ve been doing it well without realizing because HP and LP were the only times I did that. I have a few new plugins to use including ones for HP/LP (bx_cleansweep Pro) but will check for other plugins. I know Pro Q3 has different modes for phase.

[astralprojection]

Is there a benefit to mixing/mastering at 192khz? If the end listener can't tell the difference on 44.1/48 sample rates and your CPU gets bogged down, it might be better to compromise and stick to 96

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

I’m going to do more research but definitely I will refrain from using linear phase on my Fruity/Fabfilter EQs when it doesn’t seem necessary.

Only ever use linear phase if you absolutely don't want to disturb phase. So for mastering it can make sense to use linear phase for the LP, HP filtering and delicate bass work, in the sub 0-250hz range.

But, any other eq than this, linear phase is absolutely not necessary and can even sound worse than regular ol zero latency. Only will extreme filtering and cuts/boost change phase in audible ways - except one area which is the bass range. I do prefer proq3 in lin phase mode whenever I eq either sub 200 hz on a master, or when processing a kickdrum. For the bassline, zero latency hp filtering is actually beneficial, cause you can use it as you would an all pass filter, meaning you can shift or even rotate phase to fit better with the kickdrum.

And for mastering using non linear phase for boosts or cut from 250hz and up, can actually sound better.

So, to make it short, I only ever use lin phase for hp and LP filters in mastering, delicate eq work in bass area in mastering, and HP a kickdrum, which I rarely ever do.
So pretty much only two reasons to use linear phase IMHO. But never forget the golden rule, if it sounds good you're doing it right.
There are some technicals that don't change though, and are not subjective.
Oh and pro-mb simply sounds better all the time, in linear phase mode. At least to my ears.

Ahh okay, think I’ve been doing it well without realizing because HP and LP were the only times I did that. I have a few new plugins to use including ones for HP/LP (bx_cleansweep Pro) but will check for other plugins. I know Pro Q3 has different modes for phase.

Natural phase on proq3 is pretty much the best option (although I never use it) when you aren't sure, because it only affects phase when it has to, and never when it doesn't have to. It should say adaptive phase ".

[Ploki]

natural phase in proQ3 if i recall corretly is minimal phase but with corrections at the top extreme where so called "cramping" occurs. Some EQs deal with that with oversampling.

I.e. if you use a shelve filter, on a non-oversampled normal digital EQ, the phase response will "cramp" and appear more "bell like" towards the nyquist. With ProQ3 it theoretically extends into infinity like with a real analog EQ.

[xbitz]

today I was voted for iZotope

Product Price
iZotope Ozone Elements £90.91

Coupon Code Discount: £87.38
Virtual Cash Used: £3.53
VAT: £0.00

TOTAL AMOUNT PAID: £0.00

Use Coupon – PB5
Valid until 14th July (23:59 PST)
pluginboutique

[astralprojection]

natural phase in proQ3 if i recall corretly is minimal phase but with corrections at the top extreme where so called "cramping" occurs. Some EQs deal with that with oversampling.

I.e. if you use a shelve filter, on a non-oversampled normal digital EQ, the phase response will "cramp" and appear more "bell like" towards the nyquist. With ProQ3 it theoretically extends into infinity like with a real analog EQ.

yes that is true! but pro q doesnt have cramping even in zero latency mode either IIRC, and it is my understanding that their "natural phase" acts like linear phase on filters or extreme eq movements, and acts like "zero latency" when you are just making small moves. But it was a long time since I read a manual

[abject39]

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

Mathematically-even sample rate conversion has not been a thing since late 90s

Ozone allows end-user input up to 5 places after the decimal point (giving full access to 32-bit precision input), which it uses throughout all processing. It possibly uses 64-bit processing in areas internally. Sloppy is the last thing I would call that calculation and access level. That is well within the limits of high precision.

Fabfilter not possibly but confirmed uses 64-bit processing internally (and 32bit FP on outputs)
Fabfilter also allows full decimal places, it just doesn't display them because it's stupid and unecessary.
If you type in "-0.55dB" or "-0.554593845" the output of two Pro-Q3 instances will not null anymore.
So you have both calculation and access level AND low CPU usage.

I'm not saying that iZotope isn't accurate, but the CPU hit is because it's not coded as well as efficiently.
Fabfilter is a robust tool that's quick to work with. Not for the price of accuracy, but for the price of money, because it costs twice-three times as much as iZotope.
That's why you don't have bugs, ever, and why you get M1 support after a month after it's released, while iZotope is still chugging behind with some of their stuff.

What do you mean mathematically-even sample rate conversion hasn't been a thing since the 90s? 44.1 never stopped evenly dividing into 88.2. 192kHz has never lost its ability to divide by 48kHz four times evenly. Do you disagree just for the sake of disagreement?

Floating-point INPUT makes a big difference in the case of precision. Internal calculations of user data can use higher precision, but it would not yield any difference if the input data is truncated. It is possible that FF may present integers to users while using floating numbers under the hood, but that goes back to having less precision because setting the same value twice would technically yield different results. This has been my experience as a programmer.

Update status is not an indication of code "sloppiness." A number of reasons could delay updates, ranging from refactoring code and other priorities, all the way to reduced staffing and system mergers (with Native Instrument). What I'm saying is that correlation does not equal causation.

[abject39]

Is there a benefit to mixing/mastering at 192khz? If the end listener can't tell the difference on 44.1/48 sample rates and your CPU gets bogged down, it might be better to compromise and stick to 96

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

I’m going to do more research but definitely I will refrain from using linear phase on my Fruity/Fabfilter EQs when it doesn’t seem necessary.

Linear Phase EQ has very few use cases. The main reason to use it is to preserve the amplitude of audio content. Outside of that the disadvantages outweigh the advantages. Phase shifting is inherit of the equalization process. Without phase-shift, you have no equalization. Linear phase EQ's phase-shift twice; once, to equalize and a second time to offset the shift. This introduces pre-ringing and also creates latency. There are few cases where this would be more useful than just regular parametric equalization.

[abject39]

natural phase in proQ3 if i recall corretly is minimal phase but with corrections at the top extreme where so called "cramping" occurs. Some EQs deal with that with oversampling.

I.e. if you use a shelve filter, on a non-oversampled normal digital EQ, the phase response will "cramp" and appear more "bell like" towards the nyquist. With ProQ3 it theoretically extends into infinity like with a real analog EQ.

yes that is true! but pro q doesnt have cramping even in zero latency mode either IIRC, and it is my understanding that their "natural phase" acts like linear phase on filters or extreme eq movements, and acts like "zero latency" when you are just making small moves. But it was a long time since I read a manual

Dan Worrall made a popular video on YouTube comparing this to the stock Cubase EQ. I call out how his interpretation of the test results are false. Pro-Q's inability to cramp is actually a limitation, not a benefit, albeit one that most people would prefer. Pro-Q oversamples. This behavior is locked. There is no way to adjust it. Cramping comes from a lack of oversampling, like you mentioned. The sample rate limits the EQ. Pro-Q oversamples internally, so it has no choice but to extend pass the viewable frequency. It does not have to oversample very high. It only needs to extend past the workable range of the EQ enough to account for the furthest adjustment it can make.

Edit: To clarify, regarding the YouTube video I mentioned, oversampling was a Pro-Q limitation compared to the Cubase stock EQ because the stock EQ could equalize with or without oversampling. Pro-Q had no way of matching that behavior.

[airon]

Fabfilter plugins are workhorses. You just need to take a look at Dan Worrals tutorials and intro videos on their Youtube channel to get a sense of what they're capable of.

Izotope has lots of great tools as well, but they don't have Dan to explain stuff making things simple and quick to understand. They have quite a bit of overlap in some of their mixing products, so do your research. They're also trying to jump on the subscription bandwagon.

Fabfilter works with serials you paste in to the authorization window of the plugin. I couldn't be happier with that. The installers are tiny, fast and efficient.

Izotope has an installer application that used to be god aweful in the beginning. You can get separate installers but they're larger and clunkier to use. The best installer application I find is that of Plugin Alliance, though I'm not a huge fan of their authorization handling. PA is a bit opaque for me.

Izotopes authrization is decent but a mess. You CAN authorize a machine, store an authorization on an iLok(in some cases mandatory like the Stratus&co reverbs) or store it on a USB stick. It is not always obvious which product does which. The main install application just did machine authorization without asking the last time I used it, which I detested. Overall at the time I was using it(~1.5 years ago) it was an unprofessional shit show to my eyes. You're better off getting the single installers, but that may have changed. Check with other users.

I use RX 8 Advanced all day in my work. The Izotope stuff works great. The tools are excellent in what they do.

All the Fabfilter plugins however are way more efficient and easier to use. For a professional that's more important, and then there's the ease of getting, installing and authorizing the tools.

Test 'em. You can test them all for free. And watch those Dan Worral tutorials and intro videos. They're a good resource.

[astralprojection]

natural phase in proQ3 if i recall corretly is minimal phase but with corrections at the top extreme where so called "cramping" occurs. Some EQs deal with that with oversampling.

I.e. if you use a shelve filter, on a non-oversampled normal digital EQ, the phase response will "cramp" and appear more "bell like" towards the nyquist. With ProQ3 it theoretically extends into infinity like with a real analog EQ.

yes that is true! but pro q doesnt have cramping even in zero latency mode either IIRC, and it is my understanding that their "natural phase" acts like linear phase on filters or extreme eq movements, and acts like "zero latency" when you are just making small moves. But it was a long time since I read a manual

Dan Worrall made a popular video on YouTube comparing this to the stock Cubase EQ. I call out how his interpretation of the test results are false. Pro-Q's inability to cramp is actually a limitation, not a benefit, albeit one that most people would prefer. Pro-Q oversamples. This behavior is locked. There is no way to adjust it. Cramping comes from a lack of oversampling, like you mentioned. The sample rate limits the EQ. Pro-Q oversamples internally, so it has no choice but to extend pass the viewable frequency. It does not have to oversample very high. It only needs to extend past the workable range of the EQ enough to account for the furthest adjustment it can make.

Edit: To clarify, regarding the YouTube video I mentioned, oversampling was a Pro-Q limitation compared to the Cubase stock EQ because the stock EQ could equalize with or without oversampling. Pro-Q had no way of matching that behavior.

interesting. But how come you interpret it as a limitation rather than a well made eq? if you say it has internal oversampling, well, i cant say, so Id have to believe you as I have not read the manual. did not realise it had hidden oversampling and it kind of peaks my interest as to why.

however, why cramping is a benefit Im not sure, and the cubase stock eq (which i use on 99% of channels; and only pro-q when mastering or when I need lin phase) is great - but well, could you clarify a bit more about your analysis?
And I dont think I mentioned that lack of cramping comes from oversampling. Thats news to me. I wasnt previously aware what and what not made cramping, but I didnt think it had to do with a hidden oversampling feature.

Ive seen his videos, I think all of them both on his own channel and the fabfilter channel.

[astralprojection]

I use RX 8 Advanced all day in my work. The Izotope stuff works great. The tools are excellent in what they do.

me too, But i barely only ever use it to Upsample from xxk to 192k, then i master that new wave in cubase at 192k, and resample back to 44k in the end also using rx8. I think it has a wonderful resampling algorithm and you can control exactly how much aliasing you want (i dont want ANY, but hey I guess santa isnt real either), and if its linear phase or not, and exactly where the cutoff filter is going to be.
Ive also used their Music Rebalance tool alot, for remixing purposes its great. And I guess a few other things-
Izotope made some wonderful little tools in rx8.
Ozone not so much. (and ozone is really what many of us think when we think of izotope. i think. )

[Ploki]

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

Mathematically-even sample rate conversion has not been a thing since late 90s

Ozone allows end-user input up to 5 places after the decimal point (giving full access to 32-bit precision input), which it uses throughout all processing. It possibly uses 64-bit processing in areas internally. Sloppy is the last thing I would call that calculation and access level. That is well within the limits of high precision.

Fabfilter not possibly but confirmed uses 64-bit processing internally (and 32bit FP on outputs)
Fabfilter also allows full decimal places, it just doesn't display them because it's stupid and unecessary.
If you type in "-0.55dB" or "-0.554593845" the output of two Pro-Q3 instances will not null anymore.
So you have both calculation and access level AND low CPU usage.

I'm not saying that iZotope isn't accurate, but the CPU hit is because it's not coded as well as efficiently.
Fabfilter is a robust tool that's quick to work with. Not for the price of accuracy, but for the price of money, because it costs twice-three times as much as iZotope.
That's why you don't have bugs, ever, and why you get M1 support after a month after it's released, while iZotope is still chugging behind with some of their stuff.

What do you mean mathematically-even sample rate conversion hasn't been a thing since the 90s? 44.1 never stopped evenly dividing into 88.2. 192kHz has never lost its ability to divide by 48kHz four times evenly. Do you disagree just for the sake of disagreement?

Floating-point INPUT makes a big difference in the case of precision. Internal calculations of user data can use higher precision, but it would not yield any difference if the input data is truncated. It is possible that FF may present integers to users while using floating numbers under the hood, but that goes back to having less precision because setting the same value twice would technically yield different results. This has been my experience as a programmer.

Update status is not an indication of code "sloppiness." A number of reasons could delay updates, ranging from refactoring code and other priorities, all the way to reduced staffing and system mergers (with Native Instrument). What I'm saying is that correlation does not equal causation.

I don't know any algorithm that would yield different results when going even integers conversions vs interpolation. The problem isn't interpolation, it's antialiasing filtering. Speed isn't different and quality isn't different, it's irrelevant for SRC.

Fabfilter has floating point input... 32bit FP I/O and 64bit FP internal processing.
What's displayed vs what's internally doesn't meant different results, just the display is truncated to two decimal places.
your assumption about fabfilter has been wrong since the beginning on just about everything.
It has great CPU usage because it's coded well and optimised well, not because it compromises accuracy and quality.

iZotope had long standing bugs where display would lag on macOS terribly and be unresponsive. It's accurate and great, but it's not MORE accurate than fab by any means and it's certainly not as efficient.

However for less money you get more tools and its probably the most encompassing FX suite you can buy.

It really doesn't matter why iZotope takes forever to update, i'm just saying fabfilter doesn't because it has their codebase in check, and it speaks about hygiene of the developer if they need forever to update.

[Ploki]

natural phase in proQ3 if i recall corretly is minimal phase but with corrections at the top extreme where so called "cramping" occurs. Some EQs deal with that with oversampling.

I.e. if you use a shelve filter, on a non-oversampled normal digital EQ, the phase response will "cramp" and appear more "bell like" towards the nyquist. With ProQ3 it theoretically extends into infinity like with a real analog EQ.

yes that is true! but pro q doesnt have cramping even in zero latency mode either IIRC, and it is my understanding that their "natural phase" acts like linear phase on filters or extreme eq movements, and acts like "zero latency" when you are just making small moves. But it was a long time since I read a manual

Dan Worrall made a popular video on YouTube comparing this to the stock Cubase EQ. I call out how his interpretation of the test results are false. Pro-Q's inability to cramp is actually a limitation, not a benefit, albeit one that most people would prefer. Pro-Q oversamples. This behavior is locked. There is no way to adjust it. Cramping comes from a lack of oversampling, like you mentioned. The sample rate limits the EQ. Pro-Q oversamples internally, so it has no choice but to extend pass the viewable frequency. It does not have to oversample very high. It only needs to extend past the workable range of the EQ enough to account for the furthest adjustment it can make.

Edit: To clarify, regarding the YouTube video I mentioned, oversampling was a Pro-Q limitation compared to the Cubase stock EQ because the stock EQ could equalize with or without oversampling. Pro-Q had no way of matching that behavior.

Minimal phase mode doesn’t oversample tho. I could match it to Logic’s channel EQ perfectly.
Please provide the video but given your input here forgive me if i’m sceptical.

Also the fact that Fabfilter confirmed that ProQ 3 does NOT oversample.
Iirc its a FIR filter tacked on at the nyquist to correct for cramping. Cpu usage also doesn’t corellate with oversampling. Also fabfilter doesn’t Hide oversampling anywhere else.

Edit: i do agree with you re: linearphase

[abject39]

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

Mathematically-even sample rate conversion has not been a thing since late 90s

Ozone allows end-user input up to 5 places after the decimal point (giving full access to 32-bit precision input), which it uses throughout all processing. It possibly uses 64-bit processing in areas internally. Sloppy is the last thing I would call that calculation and access level. That is well within the limits of high precision.

Fabfilter not possibly but confirmed uses 64-bit processing internally (and 32bit FP on outputs)
Fabfilter also allows full decimal places, it just doesn't display them because it's stupid and unecessary.
If you type in "-0.55dB" or "-0.554593845" the output of two Pro-Q3 instances will not null anymore.
So you have both calculation and access level AND low CPU usage.

I'm not saying that iZotope isn't accurate, but the CPU hit is because it's not coded as well as efficiently.
Fabfilter is a robust tool that's quick to work with. Not for the price of accuracy, but for the price of money, because it costs twice-three times as much as iZotope.
That's why you don't have bugs, ever, and why you get M1 support after a month after it's released, while iZotope is still chugging behind with some of their stuff.

What do you mean mathematically-even sample rate conversion hasn't been a thing since the 90s? 44.1 never stopped evenly dividing into 88.2. 192kHz has never lost its ability to divide by 48kHz four times evenly. Do you disagree just for the sake of disagreement?

Floating-point INPUT makes a big difference in the case of precision. Internal calculations of user data can use higher precision, but it would not yield any difference if the input data is truncated. It is possible that FF may present integers to users while using floating numbers under the hood, but that goes back to having less precision because setting the same value twice would technically yield different results. This has been my experience as a programmer.

Update status is not an indication of code "sloppiness." A number of reasons could delay updates, ranging from refactoring code and other priorities, all the way to reduced staffing and system mergers (with Native Instrument). What I'm saying is that correlation does not equal causation.

I don't know any algorithm that would yield different results when going even integers conversions vs interpolation. The problem isn't interpolation, it's antialiasing filtering. Speed isn't different and quality isn't different, it's irrelevant for SRC.

Fabfilter has floating point input... 32bit FP I/O and 64bit FP internal processing.
What's displayed vs what's internally doesn't meant different results, just the display is truncated to two decimal places.
your assumption about fabfilter has been wrong since the beginning on just about everything.
It has great CPU usage because it's coded well and optimised well, not because it compromises accuracy and quality.

iZotope had long standing bugs where display would lag on macOS terribly and be unresponsive. It's accurate and great, but it's not MORE accurate than fab by any means and it's certainly not as efficient.

However for less money you get more tools and its probably the most encompassing FX suite you can buy.

It really doesn't matter why iZotope takes forever to update, i'm just saying fabfilter doesn't because it has their codebase in check, and it speaks about hygiene of the developer if they need forever to update.

You can read about it and view comparisons at http://src.infinitewave.ca/help.html. All sample rate conversion is not equal, even if it is the same algorithm. The starting and final sample rate can determine the accuracy of the result. It is easier to convert 192 into 48 than it is into 41 since the division will generate remainders.

[Ploki]

I would not advise the combination of linear phase and 192kHz sample rate for mixing and mastering, just for the sake of doing it. High sample rates can be helpful. For example, it can be beneficial for stretching audio, avoiding aliasing, and mathematically-even sample rate conversion.

Mathematically-even sample rate conversion has not been a thing since late 90s

Ozone allows end-user input up to 5 places after the decimal point (giving full access to 32-bit precision input), which it uses throughout all processing. It possibly uses 64-bit processing in areas internally. Sloppy is the last thing I would call that calculation and access level. That is well within the limits of high precision.

Fabfilter not possibly but confirmed uses 64-bit processing internally (and 32bit FP on outputs)
Fabfilter also allows full decimal places, it just doesn't display them because it's stupid and unecessary.
If you type in "-0.55dB" or "-0.554593845" the output of two Pro-Q3 instances will not null anymore.
So you have both calculation and access level AND low CPU usage.

I'm not saying that iZotope isn't accurate, but the CPU hit is because it's not coded as well as efficiently.
Fabfilter is a robust tool that's quick to work with. Not for the price of accuracy, but for the price of money, because it costs twice-three times as much as iZotope.
That's why you don't have bugs, ever, and why you get M1 support after a month after it's released, while iZotope is still chugging behind with some of their stuff.

What do you mean mathematically-even sample rate conversion hasn't been a thing since the 90s? 44.1 never stopped evenly dividing into 88.2. 192kHz has never lost its ability to divide by 48kHz four times evenly. Do you disagree just for the sake of disagreement?

Floating-point INPUT makes a big difference in the case of precision. Internal calculations of user data can use higher precision, but it would not yield any difference if the input data is truncated. It is possible that FF may present integers to users while using floating numbers under the hood, but that goes back to having less precision because setting the same value twice would technically yield different results. This has been my experience as a programmer.

Update status is not an indication of code "sloppiness." A number of reasons could delay updates, ranging from refactoring code and other priorities, all the way to reduced staffing and system mergers (with Native Instrument). What I'm saying is that correlation does not equal causation.

I don't know any algorithm that would yield different results when going even integers conversions vs interpolation. The problem isn't interpolation, it's antialiasing filtering. Speed isn't different and quality isn't different, it's irrelevant for SRC.

Fabfilter has floating point input... 32bit FP I/O and 64bit FP internal processing.
What's displayed vs what's internally doesn't meant different results, just the display is truncated to two decimal places.
your assumption about fabfilter has been wrong since the beginning on just about everything.
It has great CPU usage because it's coded well and optimised well, not because it compromises accuracy and quality.

iZotope had long standing bugs where display would lag on macOS terribly and be unresponsive. It's accurate and great, but it's not MORE accurate than fab by any means and it's certainly not as efficient.

However for less money you get more tools and its probably the most encompassing FX suite you can buy.

It really doesn't matter why iZotope takes forever to update, i'm just saying fabfilter doesn't because it has their codebase in check, and it speaks about hygiene of the developer if they need forever to update.

You can read about it and view comparisons at http://src.infinitewave.ca/help.html. All sample rate conversion is not equal, even if it is the same algorithm. The starting and final sample rate can determine the accuracy of the result. It is easier to convert 192 into 48 than it is into 41 since the division will generate remainders.

i'm aware of that page. It's for comparing SRC algorithms. I didn't say all algorithms are the same, i said that today it's mostly about filtering and anti-alising when you downsample and that interpolation quantisation noise is too low to be relevant.
there's also nothing about even number divisions on the page you linked to
https://imgur.com/a/XXBalPr