v6.29+dev0531 - May 31 2021

[mabian]

v6.29+dev0531 - May 31 2021

• * Includes feature branch: render normalization
• * Includes feature branch: MIDI editor note reordering
• * Includes feature branch: EEL2 x86_64/SSE
• * Includes feature branch: VST3 bridging
• * Includes feature branch: media item lanes
• + JSFX: calculate "true peak" in loudness meter
• + JSFX: display true peak clip count in loudness meter

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[Phazma]

I have seen that in the normalize-render window True Peak has replaced peak! PLEASE bring back normal peak too! I've been so excited about it..

[Phazma]

Otherwise thanks for True Peak in the jsfx, works nicely and within the +-0.1 range with other meters.

[chmaha]

Also useful in the render options would be normalizing to both LUFS-M and LUFS-S for K-meter-style normalizing and also possibly for short-form content that might specify a short-term or momentary max but not an integrated. I actually don't know of any such standard off the top of my head and the EBU short-form spec is for -23 LUFS integrated + no more than -15 LUFS short-term i.e. the short-term is dealt with during mixing/mastering. But in any case, I use LUFS-M all the time for classical to recreate a K-20 workflow.

+1 on showing both true peak and regular peak in the render analysis.

[mawi]

I have heard True Peak is not True Peak at all but an estimated value. Especially in the treble band there are measurement inaccuracies.
A sample peak meter is more accurate.

[chmaha]

Originally Posted by mawi

I have heard True Peak is not True Peak at all but an estimated value. Especially in the treble band there are measurement inaccuracies.
A sample peak meter is more accurate.

A true-peak meter oversamples x4 (EBU technical requirement) at 44.1k and 48k to read inter-sample peaks. It is definitely more accurate than a sample peak meter that does not show true waveform peaks but only sample peaks.

[Phazma]

Originally Posted by mawi

I have heard True Peak is not True Peak at all but an estimated value. Especially in the treble band there are measurement inaccuracies.
A sample peak meter is more accurate.

It depends on the DA converter when clipping occurs (and on the encoding, if that is taking place). True Peak is definitely useful for catching intersample peaks and helps prevent clipping. Also certain true peak max levels are often requested in the post prod. world

Nonetheless I am glad to see that I am not the only who cares about regular sample peaks. They have been the metering standard for long and should definitely be a possible normalization target and visible in the render analysis!

I’d say the loudness meter could do without them but I think it is better to have them also there (in addition to TP). Who doesn’t need them can hide them and who wants big sample peak meters might be happy to have them available.

[Phazma]

I also agree with BethHarmon, the more normalization options we have, the better it is. Different options can always be useful in different situations.

But probably the analysis in the render window would get bloatet if all of these were displayed there all the time, I’d suggest having an option to show/hide the various measurements and if all of them are hidden the analysis window would disappear. That way every user could set the render analysis up to show only the values that interest him or to not see it at all if he doesn’t care about the values.

[chmaha]

Originally Posted by Phazma

But probably the analysis in the render window would get bloatet if all of these were displayed there all the time, I’d suggest having an option to show/hide the various measurements and if all of them are hidden the analysis window would disappear. That way every user could set the render analysis up to show only the values that interest him or to not see it at all if he doesn’t care about the values.

+1. It seems the "Normalize" button is an excellent place to have checkboxes for what is shown. On second thoughts, perhaps as an option in preferences? Normalizing clearly isn't the same as analysis output.

For a default I'd suggest true peak, peak, LUFS-M, LUFS-S, LUFS-I in that order moving from smallest window to largest. Seeing RMS-I does seem very odd in the age of LUFS but as per Phazma's comment, the more the merrier for options.

[Icchan]

There's mathematically suitable way of calculating inter sample peak without oversampling, and that's sin(x)/x interpolation (Nice, short paper about the topic is HERE).

In bandwidth limited signal that calculation will produce "true peak", the real signal between the sampled points, but as with anything, you can calculate that interpolation with certain amount of points and more points you calculate, more accurate it is... but it's never perfect unless you calculate infinite amount of points.

But regardless, it's not rocket science and has been used in EE forever.

[chmaha]

One other thing with the JSFX loudness meter. We still have most held values above the meters and two below (LRA and LUFS-I). It looks really awkward and whether or not preference for held values is for top or bottom, they should all be on the same plane. FWIW, I think held values should be closest to the labels (i.e. bottom) for ease of reading. This way it would share UI decisions with so-called "big number" meters which don't work very well if they are separated from their labels.

[chmaha]

Originally Posted by Icchan

. In bandwidth limited signal that calculation will produce "true peak", the real signal between the sampled points, but as with anything, you can calculate that interpolation with certain amount of points and more points you calculate, more accurate it is... but it's never perfect unless you calculate infinite amount of points.

That seems to be the very definition of "oversampling" if you are adding points in between samples. I'm also not sure if visual oscilloscope stuff is a different kettle of fish. As it turns out the EBU set 4x oversampling as the technical spec so in a sense the decision about how to implement true peak measurement is taken out of the hands of the developers.

[Phazma]

Originally Posted by BethHarmon

+1. It seems the "Normalize" button is an excellent place to have checkboxes for what is shown. On second thoughts, perhaps as an option in preferences? Normalizing clearly isn't the same as analysis output.

Preferemces would be a fitting place but less accessible than directly from the render window (and I guess users who want to see different analysis for different projects might appreciate to set it up from the render dialog). Yes, putting it inside the normalize button can be confusing as it doesn’t depend on normalization to be shown. And a separate button in the render dialog might take too much space.

Perhaps a solution would be to make it similar as it was initally with “2nd pass render / normalize”, to dedicate 1 button to 2 functions. It would become “Render Analysis / Normalize” or something similar.

I’d almost suggest that by default no analysis is shown (as in Reaper v6.29) because many users might not really care at all. If one or more analysis options are activated a * would be shown near “Render Analysis” (just like it happens near Normalize if it is active).

If more than one analysis is shown I agree with you on sorting them from smallest to highest window. Only not sure about Peak being after True Peak. It is the standard value most people know/understand while the others are all a bit more specialised, so having Peak all the way left may help in recognising it as the “normal” peak for those not entirely familiar with true peak. But personally I am fine also with having it after TP (as long as we get it back for normalization & analysis!).

Anyway I am pretty sure the devs will know best where it makes most sense to put the options if they decide to give them to us.

[schwa]

Originally Posted by BethHarmon

One other thing with the JSFX loudness meter. We still have most held values above the meters and two below (LRA and LUFS-I).

All of the hold values are at the top. There's no max/hold value for LRA or LUFS-I (or RMS-I) because a single value is calculated for the entire content, so a max/hold would not be meaningful. There's only a current value.

[chmaha]

Originally Posted by schwa

All of the hold values are at the top. There's no max/hold value for LRA or LUFS-I (or RMS-I) because a single value is calculated for the entire content, so a max/hold would not be meaningful. There's only a current value.

OK, I understand. My bad, I wasn't thinking clearly. However, on completion of a playback my eyes are drawn to two competing opposite diagonals whereas my brain wants to read left to right. Eh, maybe I'll get used to it or maybe a big numbers meter option is what I'm looking for Brilliant work on all of this, btw.

[mawi]

I hope that all the oversampling for "true peak" doesn't eat up so much computing power, or I can turn it off.

[drew]

"trims existing items behind new recording (tape mode)" still not working for me in this dev build. (6.29 release is fine when I reinstall).

Dev builds generates new takes even in "tape mode" and switching to "layers mode" leaves me stuck there no matter what mode I select.

Happy to share ini if it helps.

Thanks,

Drew

[schwa]

Originally Posted by drew

"trims existing items behind new recording (tape mode)" still not working for me in this dev build. (6.29 release is fine when I reinstall).

Dev builds generates new takes even in "tape mode" and switching to "layers mode" leaves me stuck there no matter what mode I select.

I responded to your previous post, but I know the dev threads have been passing by quickly these days...

Originally Posted by schwa

I can't reproduce this at all unfortunately. The word "layers" has been removed from this submenu, so I wonder if you have a customized menu that has different actions from the defaults?

[Berg]

For render normalize options, we would appreciate to normalize our mix to the loudness target (-23.0 for example) AND to the max true peak (-3 dBTP for example), if it's possible to have both in one process !

[Berg]

Thanks for adding true peak and LRA !

And please consider these other remarks below :

We would need an "auto" option ON or OFF to accumulate the Loudness values when playing different items. For now, every time we play, the fx reset the values. Also a reset knob to reset the values whenever we want.

Maybe add a way to show more clearly the max true peak value considering all the channels so that we can quickly read the digital value. Same for Max short term loudness value, it is just a question of reading. Maybe add (could be an option) digital values showing the results under the graphs with bigger digits (Max True peak, Max Short Term, Max Momentary)
Max true peak value becomes red if it goes above our max true peak target value (-3 dBTP or -1 dBTP for example).

A different color like red that would be linked to the loudness target when showing the Integrated loudness meter. When the meter goes above -23.0, the blue color becomes red (red above the target, blue below the target) so that we easily read the values. The target loudness value on the right side , in the metering scale, could be in another color so we can identify our target.

[chmaha]

Originally Posted by Berg

We would need an "auto" option ON or OFF to cumulate the Loudness values when playing different items. For now, every time we play, the fx reset the values. Also a reset knob to reset the values whenever we want.

On my machine at least using +dev0531, values do accumulate in between playings and to reset I just click anywhere on the meter.

EDIT: Ah, I know what's happening. I was using the meter in Monitoring FX and it accumulates whereas when placed on Master bus it does reset on restarting playback. Clicking to reset during playback still works though.

[Phazma]

Originally Posted by Berg

For render normalize options, we would appreciate to normalize our mix to the loudness target (-23.0 for example) AND to the max true peak (-3 dBTP for example), if it's possible to have both in one process !

This would be very useful indeed but it requires to first do the normalization and afterwards run the render through a TP limiter. It has been requested several times in the last +dev threads but given that it hasn't been implemented I guess the devs (rightly) believe it would open too big of a can of worms with countless requests on how to implement it (native limiter, custom limiter [+ what happens if custom plugin is no limiter?], adjustable settings etc..). Or perhaps it is just not their paradigm to allow processing on render that could audibly alter the waveform.

I also don't really know of situations where someone is required to deliver a render hitting a certain true peak only, without a loudness target. So I am not sure how useful allowing TP as a normalization target is anyway, but I am sure there are situations where people appreciate to have it.

For reaching both loudness and true peak targets the best way to go (as of now) to me seems to be just render in a FP format while normalizing to LUFS-I (-23 for example) and then load the render into a clean Reaper session and render it again through a TP-Limiter of choice with the wanted dBTP ceiling (-3 for example) without any render normalization going on.

[Phazma]

Ah btw schwa.. what about including also the action "Calculate loudness of selected tracks, including take and track FX and settings, via dry run render"? Most of the times I think item analysis is more useful but track analysis might come in handy too sometimes.

[chmaha]

Originally Posted by Phazma

For reaching both loudness and true peak targets the best way to go (as of now) to me seems to be just render in a FP format while normalizing to LUFS-I (-23 for example) and then load the render into a clean Reaper session and render it again through a TP-Limiter of choice with the wanted dBTP ceiling (-3 for example) without any render normalization going on.

I'd suggest sticking the loudness meter after a true peak limiter on the master bus. If the loudness meter had a button to auto add/remove gain based on reading and target set (see Klangfreund Multimeter functionality) you would essentially be adding gain into the limiter thereby achieving both loudness and peak targets. Note that the calculation may not be quite exact which is why my ebu-norm script does a second pass. I'm pretty sure the first pass would be within the accepted spec though. In the case of JSFX loudness meter, you would then just manually add a little more gain to achieve the correct loudness.

For faster-than-realtime loudness + peak conforming it is definitely a can of worms. I'd suggest setting up your limiter as above and do a dry run render with normalization to then pass the "norm" value to the loudness meter or a 3rd-party gain plugin like airwindows purest gain. Or, even better, have the ability to do a master bus dry run render from the loudness meter (perhaps just showing a progress bar / percent complete of sorts) to automatically add the required gain without having to play through the whole material in realtime.

[svijayrathinam]

A bug in this version which isn't there in the commercially released version.


Steps to reproduce

Set the following preference

1. Options/New recording that overlaps existing media items/Trims existing items behind new recording (Tape Mode) - Set this preference on

2. Record an audio item

You will find reaper still records takes.

Can you pls fix this ?

[mawi]

Peak normalization batch processing (without truepeak option) of many audio files (Drum one shot samples) in many folders and subfolders would also be very useful for me.

[schwa]

Originally Posted by svijayrathinam

A bug in this version which isn't there in the commercially released version.

Please see post #18 above, I'm not able to reproduce this. It may have to do with a project loading with older settings, so a sample project (ideally a small one) would be helpful.

[Phazma]

Originally Posted by mawi

Peak normalization batch processing (without truepeak option) of many audio files (Drum one shot samples) in many folders and subfolders would also be very useful for me.

+1! Would be very useful for creating sample packs!

Actually I think peak normalization (and perhaps also all the loudness normalization targets) would be very nice to have in the Batch Converter too, not only in the render dialog.

[Thunderfinger]

Originally Posted by BethHarmon

On my machine at least using +dev0531, values do accumulate in between playings and to reset I just click anywhere on the meter.

EDIT: Ah, I know what's happening. I was using the meter in Monitoring FX and it accumulates whereas when placed on Master bus it does reset on restarting playback. Clicking to reset during playback still works though.

The EBUR128 Loudness Measurement V2.11 (TBProAudio) JS Has the option to auto reset on play or accumulate readings even in monitoring FX. That function saves me thousands of clicks every day, it would be great to have in the loudness meter.

[Phazma]

I found a Midi editor glitch that I can't trigger in the official release.

When scrolling the editor all the way up (or zooming out so that all pitches are visible) the piano keys disappear.

[mccrabney]

note reorder bug:

1- open midi item
2- reorder a note
3- hit undo
4- attempt to reorder note again
5- issue: user cannot reorder notes anymore
6- note: this occurs regardless of track/item. entering another midi item sees the same behavior. closing/reopening REAPER fixes the issue.

[mccrabney]

when you haven't yet named any notes, and you choose to re-order a note, there's not a lot of visual feedback indicating where the note is being dragged. you have to look closely at the note numbers.

would you please consider adding some sort of highlight? maybe emboldening of the note-name area while it's being dragged? i think having the name being bold-while-dragging would do the trick.

[Berg]

Yes so if we want to accumulate the values in between playings, for now it is not possible

Originally Posted by BethHarmon

On my machine at least using +dev0531, values do accumulate in between playings and to reset I just click anywhere on the meter.

EDIT: Ah, I know what's happening. I was using the meter in Monitoring FX and it accumulates whereas when placed on Master bus it does reset on restarting playback. Clicking to reset during playback still works though.

[chmaha]

Originally Posted by Berg

Yes so if we want to accumulate the values in between playings, for now it is not possible

You can place the loudness meter in monitoring FX and it will accumulate. Granted, I agree that the accumulation of values should also be able to happen on the master bus.

[ktm]

Hi
thanks for the new developments, the new loudness meter is great!
One thing:
when i tried embedding the UI in the MCP today, the True Peak Meter was only shown when i set all other meters were to "off". Basically i was only able to see M, S and I, but not TP, unless i deactivated all others... That was on a Mac Mini with MacOS 10.14.6.
The same thing works just fine on my Macbook, also running Mojave. Does it have to do something with the screen resolution?

A related FR:
a numbers only display would be nice. Maybe in combination with the meter.
So f.e. one could set up TP + I only as numeric display and ST as meter.

Thanks!

[MrTsonts]

I created a preset with normalize.
Then I tried to create an action using Script: cfillion_Apply render preset (create action).lua, but received:
cfillion_Apply render preset (create action).lua:191: reaper-render.ini: found unknown preset type: RENDERPRESET_EXT
No action of mine is working now (Apply render preset).

Today, before the creation of this preset, everything worked.

Removed the line that starts with "RENDERPRESET_EXT" (in reaper-render.ini)
Now everything works again.

[n997]

Originally Posted by Phazma

I found a Midi editor glitch that I can't trigger in the official release.

When scrolling the editor all the way up (or zooming out so that all pitches are visible) the piano keys disappear.

Your screen capture looks similar to what I've posted about before: https://forum.cockos.com/showpost.ph...6&postcount=19
When reporting that, I was on a system with a dedicated display for MIDI Editor, so that all pitches were visible, with ME zoomed out and scrolled up.

I did not realize that those conditions were a factor, and was planning to do further testing by manually checking ini files etc.
You've probably saved me a few hours by noticing and reporting that - thanks!

[_Stevie_]

Tooltips are popping up the MIDI editor from the arrange view.
Tooltip regression?

I just noticed it by now, but it has been there in the previous build as well:

[Phazma]

Originally Posted by n997

I did not realize that those conditions were a factor, and was planning to do further testing by manually checking ini files etc.
You've probably saved me a few hours by noticing and reporting that - thanks!

Great! I hope it is enough information for the devs too to be able to identify and resolve the glitch.

[mawi]

Originally Posted by Phazma

+1! Would be very useful for creating sample packs!

Actually I think peak normalization (and perhaps also all the loudness normalization targets) would be very nice to have in the Batch Converter too, not only in the render dialog.

1+ Exactly, very useful for samplepacks but also for the sample library in general.

Loudness normalization would certainly also be very useful for batch processing.