Quantcast
MFiT and oversampling / ISP - Gearspace.com
The No.1 Website for Pro Audio
MFiT and oversampling / ISP
Old 2nd November 2013
  #1
Lives for gear
 
karumba's Avatar
 
🎧 10 years
MFiT and oversampling / ISP

i'm currently beta-testing my script that automatically attenuates the wav masters in order to have no clipping for mastered for itunes (LINK). i was always wondering what the impact on the coder is if the PCM file was limitered with or without an ISP-limiter (i.e. limited with 4x oversampling).

please find attached two output txt files, where "output.txt" is without limiting, i.e. i just used already mastered music. "output_4xOS.txt" are the same files with a limiter having a threshold of 0dBFS & 4x oversampling. this results in only the ISP caught - if there any, since it is also likely, that the file was already limited with oversampling.

just a short explanation what you can see in the text-files:
  • gain: means how much attenuation has been applied
  • SP: sample peaks as calculated by afclip (including the max dB-value)
  • ISP: inter sample peaks as calculated by afclip (including the max dB-value)
  • when "no samples clipped" is shown, the corresponding dB-value is the needed attenuation to have no clipping at all (SP + ISP)
from the results, i derive the following conclusions:
  • the max clipping value reported by afclip is no indicator on how much attenation is needed to avoid clipping, it is typically much higher than what is really needed
  • limiting with oversampling doesn't avoid (but reduce) coder ISPs, since new ISPs are generated due to the coding process.
  • limiting with oversampling results in 0.1 to 0.2dB less needed attenation to avoid clipping with afclip
  • -1dBFS is typically sufficient to avoid clipping (as already also stated by some other MEs)
i hope you find the results interesting. i look forward to your comments.
Attached Files
File Type: txt output.txt (21.0 KB, 311 views) File Type: txt output_4xOS.txt (19.4 KB, 212 views)
Old 4th November 2013
  #2
Lives for gear
 
Greg Reierson's Avatar
 
Verified Member
5 Reviews written
🎧 10 years
When you get this perfected it could be expanded to work with lower bit rate codecs, which are still pretty common.
Old 4th November 2013
  #3
Gear Addict
 
Channel time's Avatar
 
🎧 5 years
Have you found that (well using pink noise anyways) that at 2444 the Roundtrip encoder reports clips at a lower level (e.g. -0.9) than the sample pink noise at 2496 (e,g, -0.7). . .
Old 4th November 2013 | Show parent
  #4
Lives for gear
 
karumba's Avatar
 
🎧 10 years
Quote:
Originally Posted by Greg Reierson ➑️
When you get this perfected it could be expanded to work with lower bit rate codecs, which is still pretty common.
it already works with all code rates. you can specify the code rate in the script (but 256kbit is the apple MFiT spec).

Quote:
Have you found that (well using pink noise anyways) that at 2444 the Roundtrip encoder reports clips at a lower level (e.g. -0.9) than the sample pink noise at 2496 (e,g, -0.7). . .
i'm sorry, but i couldn't understand your question. could you please elaborate?
Old 7th November 2013
  #5
Audio Alchemist
 
Lagerfeldt's Avatar
 
Verified Member
3 Reviews written
🎧 15 years
Quote:
-1dBFS is typically sufficient to avoid clipping (as already also stated by some other MEs)
4x oversampling is not enough, though. So simply aiming for -1 dBTP you need about twice that to be on the safe side if you're making MFiT masters.

I end up doing a combo and manually adjusting each master after checking with the afclip Terminal command. A small change in workflow which is a bit annoying.

I wonder if Izotope's Insight meter plug-in has 9x oversampling like some of their other products, I'm going to ask about that.

Currently I'm using NuGen Audio Vis-LM which only has 4x.
Old 7th November 2013
  #6
Lives for gear
 
karumba's Avatar
 
🎧 10 years
i meant -1dBFS incl. 4x oversampling which is the same as -1dBTP. but as you can see, the oversampling gives only a gain of 0.1-0.2dB (the amount you need less attenuation compared to no oversampling). i expected a bit more, but on the other side its also not surprising, that new ISPs are generated due to the lossy coding.

Quote:
I end up doing a combo and manually adjusting each master after checking with the afclip Terminal command. A small change in workflow which is a bit annoying.
thats exactly the reason why i wrote a script to do that automatically:
automated process for MFiT preparation
Old 7th November 2013 | Show parent
  #7
Lives for gear
 
teebaum's Avatar
 
Verified Member
5 Reviews written
🎧 10 years
Quote:
Originally Posted by karumba ➑️
i meant -1dBFS incl. 4x oversampling which is the same as -1dBTP. but as you can see, the oversampling gives only a gain of 0.1-0.2dB (the amount you need less attenuation compared to no oversampling). i expected a bit more, but on the other side its also not surprising, that new ISPs are generated due to the lossy coding.


thats exactly the reason why i wrote a script to do that automatically:
automated process for MFiT preparation

this congruent with my experience.
Old 7th November 2013 | Show parent
  #8
Audio Alchemist
 
Lagerfeldt's Avatar
 
Verified Member
3 Reviews written
🎧 15 years
Quote:
Originally Posted by karumba ➑️
i meant -1dBFS incl. 4x oversampling which is the same as -1dBTP.
BS.1770 doesn't specify the oversampling filter except for a minimum of 4x.

Quote:
but as you can see, the oversampling gives only a gain of 0.1-0.2dB (the amount you need less attenuation compared to no oversampling).
This depends on the amount of oversampling, so "-1 dBTP is the same as -1 dBTP at 4x oversampling" isn't entirely correct.

Izotope's Insight use 9x oversampling and is still BS.1770 compliant, but more useful in my opinion. So I'll be switching from NuGen Vis-LM to Insight for this purpose.

Limiting with 4x oversampling in the sidechain has the same problem which is why a 9x oversampled meter makes sense to me.

Here's Izotope's reply (same day response, I like that!):

Quote:

Insight uses 9x oversampling with a linear-phase FIR filter having 32 taps per polyphase component.

If you are concerned that the true peak levels reported by Insight are slightly higher than reported by other meters, please note that the BS.1770 standard does not precisely specify the oversampling filter, and so different meters may produce slightly different readings. The 9x oversampling exceeds the minimal 4x oversampling prescribed by BS.1770, so the reported true peak levels may be slightly higher than with other software, which puts Insight on a safer side.
Anyway, good job on the script, I'll check it out next time.
Old 7th November 2013
  #9
Lives for gear
 
karumba's Avatar
 
🎧 10 years
i agree. my point was more, that i guess even 8x oversampling wouldn't bring (much) further gain regarding how much attenuation is needed to avoid ISPs for MFiT since the gain with 4x is already quite low.
Old 7th November 2013
  #10
Audio Alchemist
 
Lagerfeldt's Avatar
 
Verified Member
3 Reviews written
🎧 15 years
Did you test this? In my test it was considerably more. 0.4 dB in one instance. I double checked because the difference was so large, but I couldn't find anything else than the difference between 4x and 9x oversampling.

I couldn't go back to the source and fix the problem in an optimum way since it was a re-master rescue job, but I think it proves that there's room for 9x oversampling.
Old 8th November 2013 | Show parent
  #11
Lives for gear
 
karumba's Avatar
 
🎧 10 years
Quote:
Originally Posted by Lagerfeldt ➑️
Did you test this?
with 4x, yes. you can find the results in the text files in post #1. just compare how much attenuation was needed.
Old 8th November 2013
  #12
Audio Alchemist
 
Lagerfeldt's Avatar
 
Verified Member
3 Reviews written
🎧 15 years
Yes, my point was test with 4x and 9x and measure the gain difference on a variety of examples.

This lead me to the result that 4x couldn't really be trusted since 1 or 2 songs on the out of 10 peaked 0.4 dB higher when tested with 9x oversampling than with 4x.

At 9x I didn't need to guess or further attenuate after the fact, which I did with 4x.

What's the highest encoding (non-ISP) related peak changes you've seen?
Old 8th November 2013
  #13
Lives for gear
 
karumba's Avatar
 
🎧 10 years
i've tested ~50 different songs. i would call that statistically quite safe. but of course, the 51th could have jumped out of the gaussian curve ;-)

Quote:
This lead me to the result that 4x couldn't really be trusted since 1 or 2 songs on the out of 10 peaked 0.4 dB higher when tested with 9x oversampling than with 4x.
0.4dB more attenuation when comparing 4x vs 9x? we are still talking about the needed attenuation for MFiT, don't we? which limiter supports 9x? maybe i'll test 8x with elephant.

Quote:
What's the highest encoding (non-ISP) related peak changes you've seen?
2.969dB - please find the attachments in my first post:

No Doubt - Hella Good.wav
gain: 0.0dB => samples clipped | SP: 15501 (max: 2.969dB) | ISP: 76845 (max: 4.287dB)
Old 8th November 2013
  #14
Lives for gear
 
Alexey Lukin's Avatar
 
Verified Member
🎧 10 years
I think that style of the recording has more impact on the values of ISPs than a particular oversampling ratio. If the recording is rich in high-frequency transients and clipping, ISPs can easily reach 0.5–1 dB. However lossy encoding often creates level excursions even higher than (and in addition to) ISPs.
Old 8th November 2013
  #15
Lives for gear
 
karumba's Avatar
 
🎧 10 years
Quote:
I think that style of the recording has more impact on the values of ISPs than a particular oversampling ratio. If the recording is rich in high-frequency transients and clipping, ISPs can easily reach 0.5–1 dB.
even much more, see my (edited) comment above (but the values are higher due to the coding). but ISPs can be avoided with oversampled limiting (for PCM).
Old 10th November 2013 | Show parent
  #16
Audio Alchemist
 
Lagerfeldt's Avatar
 
Verified Member
3 Reviews written
🎧 15 years
Quote:
Originally Posted by karumba ➑️
2.969dB - please find the attachments in my first post:

No Doubt - Hella Good.wav
gain: 0.0dB => samples clipped | SP: 15501 (max: 2.969dB) | ISP: 76845 (max: 4.287dB)
Nasty.
Old 10th November 2013
  #17
Deleted 691ca21
Guest
4.2 is crazy for ISPs, highest I've found so far is 3.9 on Kyari Pamyu Pamyu's "Pon Pon Pon" track.
Old 4th January 2014
  #18
Tokyo Dawn Labs
 
FabienTDR's Avatar
 
Verified Member
🎧 5 years
Oversampled limiting is NOT a reliable cure to the problem. It's a much more complex problem, Orban wrote an excellent article the problem of controlling overshoots in a bandlimited (and non-linear processed, e.g. clipped/limited) environment. It does not relate to any Apple niche technology , but the problem he describes is equivalent to the one discussed here (including lossy formats).

http://www.orban.com/brochures/white...%20Systems.pdf

This is a very rich article from a seasoned engineer, so it's worth to read carefully. A very relevant info he gives is:

"Another way to create problems is to perform simple digital clipping, where every sample exceeding a fixed positive or negative threshold is replaced by a sample at that threshold. Just as is the case in the analog world, clipping produces significant amounts of harmonic energy. When one thinks about overshoot in digital systems, it is important to understand that digital clipping can produce considerable energy that goes all the way to the Nyquist frequency. Many downstream DSP operations (such as sample rate conversion) involve some kind of filtering or bandwidth reduction. As soon as a downstream lowpass filter receives our digitally clipped signal, overshoot may result.

For example, if we start with a 20 kHz bandwidth signal in our 44.1 kHz sampled system and clip, we can easily produce harmonics that would have gone to 60 kHz or more if we were in the analog domain. However, because a 44.1 kHz system cannot represent frequencies higher than 22.05 kHz, clipper-induced harmonics above 22.05 kHz will instead alias to lower frequencies.

The reconstruction filter is the last of the lowpass filters in the system. Therefore, even if every sample is constrained to a threshold value by a digital clipper, the output of the re construction filter in the analog domain can overshoot beyond this threshold. Another way of looking at this is to realize that the digital clipper only operates on samples of the waveform. It is not smart enough to anticipate what the analog output of the reconstruction filter will be. In most cases, there will be peaks in the analog output of the reconstruction filter that are higher in amplitude than any of the clipped samples emerging from the digital clipper. Consequently, clipping in the digital domain does not perfectly control peak levels in the analog domain. The problem is not caused by the filter; it is caused by clipping in a way that β€œbreaks the rules” by producing out of band energy (i.e., energy beyond the 20 kHz bandwidth of the system). In other words, clipping makes high frequency energy that the filter must remove. When this happens, overshoot ap- pears at the output of the filter. The challenge to a DSP programmer is to create signals that are limited in both bandwidth and amplitude. It is easy to do one or the other, but doing both simultaneously requires some special techniques. An ordinary lowpass filter will control the bandwidth, but not the amplitude. A clipper will control the amplitude of the individual samples, but not the bandwidth."


"Brute force" oversampled limiting and will not help control overshoot! The problem is much more complicated, because overshoots happen during bandlimiting (i.e. sample-rate conversion) and not inside the limiting process. Only specialized overshoot-free-oversampled-limiter could help, but I am not aware of any such tool in the "music engineering" market. Right know, controlling overshoots without aliasing, isp and gibbs phenomenon is hit and miss.
Old 4th January 2014
  #19
Deleted 691ca21
Guest
Great post Fabien. Now is the time to tell us you are working on just such a limiter!
Old 4th January 2014
  #20
Lives for gear
 
Alexey Lukin's Avatar
 
Verified Member
🎧 10 years
I think that an unaggressive oversampled limiter is quite suitable for prevention of ISP overshoots. Of course, aggressive clipping-style limiting will not be sufficient, even when oversampled.
Old 4th January 2014
  #21
Tokyo Dawn Labs
 
FabienTDR's Avatar
 
Verified Member
🎧 5 years
I agree, and it's worth noting that Orban's context is real-time. Offline, it's just a problem to be "aware" of.

@Babaluma: Not really, but it's an interesting challenge.
πŸ“ Reply
Topic:
Post Reply

Welcome to the Gearspace Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…

Forum Jump
Forum Jump