Replies: 4 comments 1 reply
|
@vpoguru I've recently been looking into adding this feature (of course for loops and not for cues). The problem is that the values doesn't really make so much sense for a human to read while they sure still works as a limiting decision tool for the computer. I "currently" use a very basic "mean absolute difference" of only five samples "around" the loop points in LA to judge the loop quality in the loop search algorithm. This value is usually quite small, but it does take into account the amplitude of the waveforms not only the "direction" of them - my reasoning being that a larger amplitude difference would be more audible than a smaller one. On the other hand the user can currently set a quality limit in the loop search parameters dialog that's based on how much differences would be acceptable, scaled in a rather old fashioned way according to the precision of a 16 bit audio file (please remember that it was the only thing that was allowed in GO when LA first was created). This is not really related to the quality criteria used by the loopsearch algorithm in an easy way to account for. Thus the reported loop quality cannot currently really be related to the number that the user sets... Besides, the differences of the "quality" numbers are so minuscule that the user would have a hard time setting any quality judgement only by the "numbers" themselves. I've tested various different methods of evaluating loop quality, like relative differences instead of absolute, Pearson correlation and some other based on statistics. Problem is that while they might be working beautifully in their own ways they never take everything into account and doesn't give any real help for the user to decide the actual loop quality that the human ear will hear! Thus, I'm still inclined to say as before - use your ears to decide what loop is best... And most important of all, I'm not sure how to even proceed to implement this feature request in an useful way for the user! Most of all I'd want to have a consistent number that the user sets as a loop search criteria and what the loop search algorithm uses, and also is reported, both for the existing loops and used "behind the scene" for the loop candidates. This would again mean some considerable changes for the user settings in the new version and perhaps also some changes in the loop search behavior. Problem is that I don't know yet what would be the "best" approach for it. |
|
@larspalo. Thank you for the detailed explanation — it’s clear that assessing loop quality is a nuanced process, and I appreciate the thought you’ve put into balancing algorithmic evaluation with human perception. Given that the AutoLoop settings already allow users to set a quality threshold (from 0.5 to 100.0), and that this quality value is computed for each loop to determine whether it’s acceptable, it seems that this data is already available internally. Displaying this number in the cue table wouldn’t change the underlying algorithm or require new heuristics — it would simply expose a value that the system already uses. Even if the quality number isn’t an absolute or perfect indicator of perceived audio quality, having it visible could still be valuable to users. It could help identify borderline cases or give insight into why some loops were selected while others were not. The cue table is already a technical interface, so users who refer to it are likely capable of interpreting relative values meaningfully. In short, this wouldn’t require a redefinition of quality evaluation — just a small interface enhancement that could improve transparency and user control. Would it be possible to consider this as a lightweight addition in a future release? |
Certainly. I already have it kind of "working". Though, the current visible quality that the user sets isn't really that well related to the search process and thus a bit difficult to explain what it really means. Internally it's converted/scaled into an equivalent of a floating point value of a single sample that will be used against the average difference sum of the five samples of all channels around the loop points. Now I'm testing changing the current Quality number into a more accurately describing "Max difference" (allowed). This means getting a consistent "unity" between the internal workings and what the user actually can see. Also, using the internal measurement, it would mean that I don't need to re-calculate the loop quality and convert it "backwards" to the user setting.
No, but our perception of the quality of a loop isn't really an average of the complete sum of the sounds in all the channels the way it's currently implemented. Also, my programming skills has improved a bit since 2011 which means that I'm anyway thinking of re-designing a few things internally. The thing is that if there's a click in one channel only, that's what we hear! So, I've tested changing the "quality test" to process each channel separately and use the "worst" one to describe the total difference so that it won't be "watered down" by the "better" channel. After all, if the click is audible in only one channel it still ruins the whole experience of the loop of the stereo sample... The version I'm leaning towards now is that the user setting would in the new version change its meaning to what is the allowed maximum difference for all the five samples of the worst channel. In the very worst case scenario for a square pulse wave it means that the worst match could be about 10 (1 to -1 = 2 for five samples). No "real" sample that I've tested so far has a loop with worse matching difference than about 0.06+ and it seems that for many samples a value below 0.01 won't be too obviously objectable (but a lower difference is of course better). Thus, I'm inclined to change the user setting as a maximum allowed difference range from 0.1 to 0.0001 total. Very few samples, and most likely only crossfaded ones will be better (lower total difference) than that. The main benefits of changing it this way would be:
Still, judgement cannot really be delivered only "by number", though it absolutely can be a help. There are too many other factors that might make a loop objectionable even though the waveforms at the loop points match fairly well. I recommend reading https://www.appletonaudio.com/blog/2019/on-the-perils-of-cross-fading-loops-in-organ-samples/ for some more insights. |
Just as I wrote that I found 0.279358 difference in one of the Barton samples. It of course has a very audible click and the loop is clearly mis-aligned... Aligning it back as best it can be gives a difference of 0.035980 which still clicks but if it's not amplified above "natural" amplitude it's almost not audible. Increasing the playback volume to the next step makes the click come out, albeit still very faintly. |
|
I have implemented this in the 0.12.0 version. Though, I really find it tricky to be sure about the loop quality only by reading the numbers. They are definitely a help to quickly identify problem cases, but depending on the sample itself I find that a loop with around a 0.005+ number might still (very softly) click but it's only audible if the volume is boosted a lot... Sometimes, even though the numbers are more or less the same, I'll find one loop acceptable while I'll discard another. Please test for yourself and see if it's any help at all. |
Uh oh!
There was an error while loading. Please reload this page.
Including the quality factor in the cue table would be highly beneficial. As a higher quality factor is often required to achieve a sufficient number of loops, displaying this information would make it easier to assess which loops are excellent, adequate, or borderline in quality.
All reactions