Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[6233638]

Do you have very many real world examples in your library where the Peak Level (R128) doesn't have enough headroom to adjust for Volume Level (R128)? In my library of 6400 audio tracks I found just three and it only made a 1.6 dB or less difference. I also would never play back those tracks without the entire album so it wouldn't matter anyway. The one needing the most Volume Level (R128) measures 15.8 and it has a Peak Level (R128) of -15.1 dBTP. The actual adjustment is 14.1 dB.

As I mentioned before, only 1% of the music I have analyzed so far (151/~16,000) requires more headroom than -23 LUFS provides; and most of those tracks are classical music, which would generally be played back as albums anyway. I think -23 LUFS is a very good target level for music.

Vocalpoint suggested that the target be raised to -15 LUFS though - only 38% of my library would be able to be properly normalized using that as a target level.
I think if people are finding that playback is too quiet when using Volume Leveling, the solution is to use it in conjunction with Adaptive Volume set to Peak Level Normalize, rather than raise the target level. This will ensure the current playlist is level, but plays it as loud as possible while avoiding clipping.


For videos, however, more than 50% of my library requires more headroom than -23 LUFS provides. The worst offender is a film which requires 11.9dB of additional headroom.
Overall, it seems that -30 LUFS would be a suitable target for most films though. I'm not suggesting that the default be changed, but I would like some way of adjusting it. (and using Internal Volume seems like the neatest solution)

But that doesn't tell the whole story - when you downmix to stereo, the peak and average levels can change quite a bit. Some files require additional headroom, and others don't need nearly as much.
Matt has tried a few ways of estimating it, but perceptually, I don't think it works very well for films. It seems to do a better job with music, mostly being ±3dB with the files I have tested so far.
I think the only real solution is to have an option that will also analyze the downmix. There are reasons why it's not a good idea to do this, but I can't come up with a better solution.

But it could also be argued that volume leveling is not as much of a concern for film playback, because they're going to be at least 90 minutes long, and it's not as common to be playing them back-to-back.
It's mostly a problem for videos that have been created for the web (YouTube etc.) which are stereo, but simply need more headroom.

[mwillems]

Do you have very many real world examples in your library where the Peak Level (R128) doesn't have enough headroom to adjust for Volume Level (R128)? In my library of 6400 audio tracks I found just three and it only made a 1.6 dB or less difference. I also would never play back those tracks without the entire album so it wouldn't matter anyway. The one needing the most Volume Level (R128) measures 15.8 and it has a Peak Level (R128) of -15.1 dBTP. The actual adjustment is 14.1 dB.

Only 200 tracks of mine need a positive volume adjustment (.03%). Out of those 200, there are only 4 tracks that I would play in a mixed playlist.

For me, about 1500 out of 56000 tracks require a positive adjustment, and about 1/2 of those (a little less than 800) require a positive adjustment greater than the peak level will accommodate, so this affects a little less than 2% of tracks for me.  The majority of those (about 2/3) are classical music, so probably not playlist fodder, but a substantial number of the remainder might wind up in playlists.

It's a small issue (for me), and I'm sure there are some unintended consequences I'm not seeing.  But if it were frictionless, it seems like it would be preferable to process internal volume first or in composition with volume leveling so leveling would work for those tracks too.

[mantis07]

how do I go about displaying the DR value of an analyzed song?

thanks

[Vocalpoint]

Vocalpoint suggested that the target be raised to -15 LUFS though - only 38% of my library would be able to be properly normalized using that as a target level.

I have since found out that ReplayGain is essentially = -18LUFS. And I finally found the document that I was thinking about in relation to my -15 LUFS suggestion...and it's here...

http://techblog.studio-compyfox.de/media/tech-doc/tech001_2012-Q2_K-System_v2.pdf

This document combines the best attributes of R128 with the Bob Katz "K System" and proposes a different target LUFS with the respect to music production. I feel this -16 LUFS standard is more in line with what one would have been experiencing with ReplayGain and it addresses the sharply quieter playback that the standard -23 LUFS target gives. That standard target was created to address the needs of ongoing broadcast material (voices, spots, music etc) in TV/radio and to me - simply is too aggressive a target to apply to my own library from home use.

I will be able to speak to this much better of course when I install v19 - but we are not ready for that just yet..

I hope you will give the doc a read and let me know what you think.

Cheers!

VP

[mwillems]

I have since found out that ReplayGain is essentially = -18LUFS. And I finally found the document that I was thinking about in relation to my -15 LUFS suggestion...and it's here...

http://techblog.studio-compyfox.de/media/tech-doc/tech001_2012-Q2_K-System_v2.pdf

This document combines the best attributes of R128 with the Bob Katz "K System" and proposes a different target LUFS with the respect to music production. I feel this -16 LUFS standard is more in line with what one would have been experiencing with ReplayGain and it addresses the sharply quieter playback that the standard -23 LUFS target gives. That standard target was created to address the needs of ongoing broadcast material (voices, spots, music etc) in TV/radio and to me - simply is too aggressive a target to apply to my own library from home use.

I will be able to speak to this much better of course when I install v19 - but we are not ready for that just yet..

I hope you will give the doc a read and let me know what you think.

Cheers!

VP

I seem to recall that JRiver's implementation of the ReplayGain standard was about 6 dB different than the actual standard (but tagged in a way that allowed compatibility with players using the normal standard).  The specification for the official ReplayGain standard target is -14 LUFS (89dB calibration) http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Clipping_prevention, and JRiver's implementation was -20 LUFS (83 dB calibration) to bring it in line with film mastering/movie theater calibration.

So the new volume leveling target will be about 3 dB quieter than the old volume leveling target (bracketing out other differences in the way the standards work that might affect how successfully they're hitting the target).  Subjectively, for what it's worth, the new volume leveling doesn't sound much quieter to me than the old volume leveling, just much more consistent in it's effects.

[Vocalpoint]

I seem to recall that JRiver's implementation of the ReplayGain standard was about 6 dB different than the actual standard (but tagged in a way that allowed compatibility with players using the normal standard).  The specification for the official ReplayGain standard target is -14 LUFS (89dB calibration) http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Clipping_prevention, and JRiver's implementation was -20 LUFS (83 dB calibration) to bring it in line with film mastering/movie theater calibration.

Yes - however I still added "+6db Fixed" in Volume Leveling to my playback - essentially pushing the JR implementation back to the RG standard. I have found this to be absolutely perfect for my entire library.

So the new volume leveling target will be about 3 dB quieter than the old volume leveling target (bracketing out other differences in the way the standards work that might affect how successfully they're hitting the target).  Subjectively, for what it's worth, the new volume leveling doesn't sound much quieter to me than the old volume leveling, just much more consistent in it's effects.

Good to know. I look forward to using the new system...

Q: Within all the changes made here - is it possible to just dip my toe into the R128 pool slowly when transitioning to v19? That is to say - can I count on my existing  ReplayGain values to work as usual in v19 or do I have to go all in with R128 right off the bat?

For me - my audio analysis metadata is critical and I certainly do not want to trash my library (or prematurely stop using RG) in one fell swoop when I make the move to v19. Would rather experiment (and potentially move away from RG) in a slow graduated process before going all in with R128.

Appreciate any comments on this..

VP

[6233638]

how do I go about displaying the DR value of an analyzed song?

Right click a column and select Dynamic Range (DR) to add it.

I have since found out that ReplayGain is essentially = -18LUFS.

The ReplayGain 2 specification is based upon the ITU BS.1770-2, which is what the R128 specification that JRiver have implemented in MC19 is based upon. It also specifies a target level of -23 LUFS. (actually denoted LKFS in the spec, but it's the same thing)

And I finally found the document that I was thinking about in relation to my -15 LUFS suggestion...and it's here...
http://techblog.studio-compyfox.de/media/tech-doc/tech001_2012-Q2_K-System_v2.pdf
This document combines the best attributes of R128 with the Bob Katz "K System" and proposes a different target LUFS with the respect to music production. I feel this -16 LUFS standard is more in line with what one would have been experiencing with ReplayGain and it addresses the sharply quieter playback that the standard -23 LUFS target gives. That standard target was created to address the needs of ongoing broadcast material (voices, spots, music etc) in TV/radio and to me - simply is too aggressive a target to apply to my own library from home use.

This paper is focused on music production rather than playback, and the argument throughout seems to be that there will be resistance to adopting -23 LUFS in production because it's not loud enough - which is exactly the kind of thinking that got us where we are now with highly compressed dynamics in the first place. (because it used to be that broadcast used peak normaliation) The proposed "K-System v2" is to make the transition to -23 LUFS easier, rather than going directly to it for production.
But the whole point of R128 is that it doesn't matter how loud a track was produced, it will be normalized to -23 LUFS regardless, and it puts tracks with highly compressed dynamics at a disadvantage. (because the compression was used to make them loud)

-16 LUFS means that one third of my library is unable to be normalized. Even if I remove classical tracks, it's still 27% of my library.
And in broadcast, some radio stations have already implemented R128 normalization.

I will be able to speak to this much better of course when I install v19 - but we are not ready for that just yet..

I don't think it's fair to be criticizing the -23 LUFS target, if you haven't tried it. R128 normalization ≠ ReplayGain v1.

[Vocalpoint]

I don't think it's fair to be criticizing the -23 LUFS target, if you haven't tried it. R128 normalization ≠ ReplayGain v1.

Well - I did not say (nor imply) that I have not tried/used R128.

I have been using it for a long while within my pro audio work. But normalizing a typical pop/rock track to the -23LUFS target within current tools like Wavelab 8 - which has a state of the art R128 conversion tool - is in my opinion - a perhaps a tad much. I guess I need to understand it more.

Now I did say I have not tried R128 with MC v19. Hence the reasons for my questions. Just trying to understand what's new and what's available.

Cheers,

VP

[6233638]

Well - I did not say (nor imply) that I have not tried/used R128.
I have been using it for a long while within my pro audio work. But normalizing a typical pop/rock track to the -23LUFS target within current tools like Wavelab 8 - which has a state of the art R128 conversion tool - is in my opinion - a perhaps a tad much. I guess I need to understand it more.
Now I did say I have not tried R128 with MC v19. Hence the reasons for my questions. Just trying to understand what's new and what's available.

Ah I remember we had this discussion a while ago.

Your editing tools do not appear to be simply normalizing the volume to conform to the R128 spec, but making other changes to the waveform such as adjusting the dynamic range.
R128 analysis and leveling only adjusts the volume level during playback - nothing else.

The point is that R128 analysis gives a much more accurate measurement of the track's perceived loudness than ReplayGain did, and now includes checks to prevent inter-sample clipping.

[satfrat]

Just want to give the MC Team KUDOS for developing this new volume leveling. As I use JRiver mainly as an audio player for my album library, I'm noticing an immediate improvement in audio quality and this alone was well worth the MC19 upgrade.

On the minus side, STILL no MiniView options,,,,,,,,,,,  ?


Cheers,
Robin

[mojave]

What is the difference between Peak Level (R128) and Peak Level (Sample)?

[6233638]

What is the difference between Peak Level (R128) and Peak Level (Sample)?

Peak Level (sample) measures the peak level encoded inside the file. The maximum this can be with a lossless file, is 0dB. Lossy files may have samples that are above 0dB, as they use floating point values.
Peak Level (R128) upsamples the audio before measurement, and then measures the peak level. This is known as True Peak Level, and is measured in dBTP.

This is done because when you convert a digital signal to an analog waveform, it's possible to have signal levels that go above 0dB. Particularly with modern music releases, tracks are often adjusted so that the peak sample level is encoded at -0.1dB.
Most DACs do not seem to have headroom built into them to account for this, because any headroom you leave is effectively "throwing away" SNR, so you have the possibility of clipping/distortion on playback. The only DAC I am aware of that has headroom built in and advertises this fact, is Benchmark's DAC2 models. (that doesn't mean it's the only DAC with headroom though)
This clipping is known as an inter-sample peak. The Peak Level (R128) measurement is not going to be 100% accurate (speed of analysis is a factor, and different DACs may produce different results) so there's an additional 1dB headroom to account for this variance.

Here's an example that I pulled off Google Images which illustrates the problem:


In this image, you can see that none of the samples (the squares) exceed 0dB - but the analog waveform those samples represent exceeds 0dB. This would result in clipping/distortion when played through most DACs.

[mojave]

Thanks, 6233638, for the explanation.

[contium]

Here is an article along the same lines:

http://www.indexcom.com/tech/0dBFS+/

[Denti]

I'm still using MC17, but am thinking of upgrading when MC19 is available. But a lot of the technical talk is over my head.

1) Is this feature something I can turn on and off? I like to list to albums a lot, and I don't want it affecting volume between tracks

2) Does this feature negatively impact sound quality in any way? I use FLAC and try to get the most out of these files. I don't want something interfering or changing this.

[6233638]

1) Is this feature something I can turn on and off? I like to list to albums a lot, and I don't want it affecting volume between tracks

Yes, you can turn it off. Albums are played back in such a way that all tracks are adjusted by the same amount.

2) Does this feature negatively impact sound quality in any way? I use FLAC and try to get the most out of these files. I don't want something interfering or changing this.

The short answer is that there should not be an audible change.

With a target level of -23 LUFS, you are theoretically discarding up to 4-bits of precision (6dB per bit) but with a 24-bit output that should still give you 120+dB of SNR which is beyond most DACs anyway, and still sufficient for "lossless" CD quality playback. (16-bit)

[Dave_G]

For some reason I am noticing a degradation of sound quality when using volume levelling, a not too subtle loss of clarity to the sound. I thought I'd take a look in here to see if others had experienced the same, but it appears not. It's OK for shuffle play when music is just a background thing but when using headphones and listening critically I don't like it at all. For now this feature is staying off. It's not really a big deal, I don't mind adjusting the volume as I need to.

All my files are ripped as aiff at the same sample rates as the originals, so mostly 16/44.1 with some 24/96 or 192 downloads & even a couple of DsD's as my DAC is DsD capable. I never compress anything. Don't see why that would make any difference though. I do often use DsD encoding and quite like it.

[6233638]

If you are outputting 16-bit files at 24-bit or greater (which Media Center does by default) you should not hear any degradation.

However, with the way that our hearing works, louder generally sounds better. So if you have enabled volume leveling and have not matched the volume to its previous level, you may perceive it to sound worse.

[fallsroad]

Yes, you can turn it off. Albums are played back in such a way that all tracks are adjusted by the same amount.
The short answer is that there should not be an audible change.)

Some of this discussion is admittedly over my head.

For clarity, is this a non-destructive process? There are no actual changes to audio files?

Are values written as tags in the files themselves, or stored in the library?

I ask because I have been using dbpoweramp to rip and convert files and add RG tags in the process. There is a DSP for R128 Normalization, but it rewrites the audio content of the files so i have not used it.

Thanks.

[Matt]

For clarity, is this a non-destructive process? There are no actual changes to audio files?

Are values written as tags in the files themselves, or stored in the library?

It is non-destructive.  The audio in the file is not changed in any way.

Values are stored in the library and tags and optionally used at playback time to enhance the experience.  You can turn the playback processing on or off easily.

I'm a believer in playback-time processing.  Store a perfect copy, then apply any processing at playback time.  This provides more flexibility and provides room for future improvements without ever requiring you to rerip / reencode.

[fallsroad]

It is non-destructive.  The audio in the file is not changed in any way.

Values are stored in the library and tags and optionally used at playback time to enhance the experience.  You can turn the playback processing on or off easily.

I'm a believer in playback-time processing.  Store a perfect copy, then apply any processing at playback time.  This provides more flexibility and provides room for future improvements without ever requiring you to rerip / reencode.

Appreciate the clarification. I'm also a believer in playback processing. My music collection is large enough that re-ripping it would be a gigantic chore. I take pains to ensure I have multiple current back ups of my entire library, specifically to avoid having to rip it over again.

Does MC19 still support ReplayGain tags?

I've used RG solely because it was non-destructive. I'm hoping the dbpoweramp folks add a DSP in future that will analyze and store the R128 info as tags.

I'll upgrade to MC19 now, and give R128 a try.

[InflatableMouse]

Does MC19 still support ReplayGain tags?

RG values are derrived from R128 values upon analysis with MC19. If there are no R128 values but there are previous RG values, MC falls back to using them.

At least, that how I understand how it works now.

[Bebop0502]

I installed the MC19 beside my MC18 in W8 and it worked as well as with MC18 as far as I can see and hear. (I only use MC18/19 for two channel stereo). Also Gizmo in my Android smartphone got it without special actions. Fine so far...

However when using "Play Now" from Gizmo showing images on the laptop plus titel and time behaves different now. When I start a new album, the cover is shown like before with readable title in negative White plus the option i use in under the gadgets meny. After some seconds the cover is fading out (like before) and the program import images from internet. Just as with MC18. But after 3-4 minutes the text is fading down in light and can't be read. When a new tune is loaded, the album cover normally shows up again but now it is so faded so it is hardly visable.

Is this something I can correct? If so, where? In MC18 it is not an issue.

[rael71]

Is it possible to display the album DR value instead of single tracks DR value?

Thanks and bye

Andrea

[InflatableMouse]

Is it possible to display the album DR value instead of single tracks DR value?

Thanks and bye

Andrea

http://yabb.jriver.com/interact/index.php?topic=82810.0

[rael71]

thank You for the answer but what I'd like to have is a field/expression called "Album DR" like the one showed with dynamic range tool on foobar to have a view grouped by that value; for example I use a sample rate grouping (see attached file) and I'd like to do the same thing with Album DR value

Anyone knows if it's possible?

Thanks and bye

Andrea

[InflatableMouse]

It should be possible to use the calculated album DR values from the thread I linked in a custom field, It shouldn't be too hard but I haven't had time to figure it out yet.

[Johnny B]

Please provide an option to (re)analyze loudness only but keep existing BPM values. As MC sometimes comes up with completely irrelevant values, I always analyze and enter them myself, and I really don't want to lose all that effort I had put into it already...

[Matt]

Please provide an option to (re)analyze loudness only but keep existing BPM values. As MC sometimes comes up with completely irrelevant values, I always analyze and enter them myself, and I really don't want to lose all that effort I had put into it already...

You could make your own field and copy the existing BPM values into it.

[Johnny B]

You could make your own field and copy the existing BPM values into it.

Thanks for the tip although it's only a workaround.
Searching the history here I found out this has been already asked as a feature request in past. With regards to this response of yours do I get it right you simply don't want to add such an option? Why?

[InflatableMouse]

I think because if they start with excluding BPM, someone else comes along asking for excluding DR values and then another wants to keep RG values. Before you know it, the analyser becomes cluttered with options to exclude each individual item. I, for one wouldn't like that.

Temporarily copying the BPM values to custom field is really quite simple and IMHO the best option. If you don't save the new field to files its very fast too.

[fmd]

Need some direction on how to make sure I am setting this correctly.  I have re-analyzed audio on my entire collection to the R128 std.  While playing my library yesterday I had wild swings in vol.  I should note I am streaming via DNLA to my Oppo BDP-105.  Previously I could set this in audio options.  Now it is grayed out saying I must adjust via Media Network/DNLA server but I see no option to do this. I also use JRemote which has no option to set this.


Any help to get this set up will be greatly appreciated

[JimH]

Make sure you have the latest build of MC19.  A DLNA bug was fixed that probably caused this.

[fmd]

I updated to the latest.  My question now is do I configure Volume Leveling/Adaptive Volume for the Player or the Device (Oppo)? Not avail for Device (Oppo).  So if setting at the Player will apply VL to my media server, what are the best settings to make sure it is setup correctly?

Thank you in advance

[weirdo12]

I don't like the new leveling system - yet anyway. It brings the volume down so low that it's impossible to play something that's been analyzed along side something that hasn't. Using Adaptive Volume helps but seems to effect the direct audio connection for some files. I think it's because I'm used to using Replay Gain with a fixed adjustment of +8db. I have paid for the version 19 upgrade but will continue to use 18.

[JimH]

This is fixed in the next build:

1. Fixed: Adaptive volume would sometimes not apply (fixed) volume adjustment on already analyzed files.

[weirdo12]

This is fixed in the next build:

1. Fixed: Adaptive volume would sometimes not apply (fixed) volume adjustment on already analyzed files.

Thanks Jim.

[jhermosillo]

Hello Jim,

I re-analyzed all my music library on MC 19....32 build, last weekend took me around 33hrs to do so, Huge library. Today I came and started MC19 and tried to check some values on the analyzed data, and it looks like everything is lost, all the library seems to be unanalized. What may happened?

John

[jhermosillo]

Jim

I am playing an album reanalyzed in MC19 and applying volume leveling and adaptive volume>peak level normalize and it clips terrible. Volume leveling is at -12.9 and peak normalization is +12.0 and is clipping really badly even having clip protection on. On MC 18 i didn't have this issue of course because I was applying +3 of fixed gain on volume leveling.

I hope this issues can be resolve soon, In the meantime I am back on MC18.

John

[6233638]

I am playing an album reanalyzed in MC19 and applying volume leveling and adaptive volume>peak level normalize and it clips terrible. Volume leveling is at -12.9 and peak normalization is +12.0 and is clipping really badly even having clip protection on. On MC 18 i didn't have this issue of course because I was applying +3 of fixed gain on volume leveling.

I hope this issues can be resolve soon, In the meantime I am back on MC18.

If you have analyzed the files with MC19, it should not be allowing them to clip, because it measures the true peak level (the Peak R128 value) and does not allow it to go above -1.0 dB.
If you want the volume level, you need to use Volume Leveling enabled on its own. Adding a +3dB adjustment (which would be equivalent to +9dB now) will not allow most files to be levelled properly. R128 requires a target of -23 LUFS (dB) for this.

Volume Leveling combined with Adaptive Volume will level all tracks in the current playlist and then push it to the maximum volume it can, while avoiding clipping.

[jhermosillo]

6233638 thanks for your reply, but maybe something is wrong because it really clips and badly, and if I use only vol leveling it goes very quite, and I need to crank my amp the vol up a lot. And I found there are several albums doing this clipping.

Anyway I hope this things get resolved in a new build, In the mean time using MC18,

Thanks for the explanation

[6233638]

6233638 thanks for your reply, but maybe something is wrong because it really clips and badly, and if I use only vol leveling it goes very quite, and I need to crank my amp the vol up a lot. And I found there are several albums doing this clipping.
Anyway I hope this things get resolved in a new build, In the mean time using MC18,
Thanks for the explanation

What are the Peak Level (R128) values for the files? Perhaps they need to be re-analyzed.

[InflatableMouse]

If you have analyzed the files with MC19, it should not be allowing them to clip, because it measures the true peak level (the Peak R128 value) and does not allow it to go above -1.0 dB.
If you want the volume level, you need to use Volume Leveling enabled on its own. Adding a +3dB adjustment (which would be equivalent to +9dB now) will not allow most files to be levelled properly. R128 requires a target of -23 LUFS (dB) for this.

Volume Leveling combined with Adaptive Volume will level all tracks in the current playlist and then push it to the maximum volume it can, while avoiding clipping.

Do you have anything else enabled? Equalizer, PEQ, Room Correction?

I found that some of the other options are not considered by volume leveling and can cause clipping.

[jhermosillo]

What are the Peak Level (R128) values for the files? Perhaps they need to be re-analyzed.

+0.1 dbTP and also some are 0.0dbtp, i did the re-analyzed and is just the same. this weird. Also coming back from MC18 all my files appeared as not analized. this is frustrating it took me like 30 hours to analyze all track, 34K+ track. I don't know if MC19 will work for me.

Thanks

John

[jhermosillo]

you are right, if I combine EQ with effects it is when clips, if i do one or the other it is ok. This should be fixed in some way. because in EQ i really do a very slight change also on effects adding a little environment.

Thanks

[Matt]

you are right, if I combine EQ with effects it is when clips, if i do one or the other it is ok. This should be fixed in some way. because in EQ i really do a very slight change also on effects adding a little environment.

Thanks

Volume leveling happens on the input signal.  It is completely independent of later processing like EQ.

If you apply effects that could cause clipping, you have a few choices:

1) Switch to Internal Volume.  This is my favorite solution, but I understand it only works well in some installations.  Explanation here: http://wiki.jriver.com/index.php/Volume#Internal_Volume_Headroom

2) Add an effect to turn the volume down (equalizer preamp, parametric volume reduction, etc.).  It doesn't matter where in the chain, since it's not a clip until output.

3) Just let the final safety valve detect the clip and turn the volume down.  This is less of an audiophile solution, but the real world results will be pretty good.

[Gl3nn]

Probably a dumb question: the results of the analysis are stored in the library?  So if, for instance, I have a need to restore/re-image my machine to a pre-analysis period, simply restoring a saved backup would have all the analysis data?  No need to re-do?

[MrC]

The analysis data is stored in the library, and by default in the new tags (and some compatibility tags which are auto-generated).  These are stored in file tags, so an Update Library (from tags) would re-read them:

MC Tags:
    Dynamic Range (DR)
    Dynamic Range (R128)
    Peak Level (R128)
    Peak Level (Sample)
    Volume Level (R128)
    Volume Level (ReplayGain)

Compatibility Tags:
   REPLAYGAIN_TRACK_GAIN
   REPLAYGAIN_TRACK_PEAK

[Gl3nn]

Thanks, MrC!

[BayensF]

MC19 makes several important improvements to audio analysis and volume leveling:

• Adoption of the R128 industry standard to analyze the loudness and dynamic range of content
  
• Ability to analyze audio for video files, including surround sound
• Smarter Volume Leveling that automatically respects intentional between track levels when playing from an album
• Volume Leveling works together with Adaptive Volume's peak level normalization
  
• Peak level is reported in decibels, measured as an R128 compliant True Peak, and reported per channel

This is a big topic, so I'll try to revisit it and post more details about the changes and the motivation at a later date.

Hi,

This is another very good and usefull addition in MC, and still under development I hope. During the development please make sure Stereo Playback from Video is taken care off. To me it seems that the impact on Stereo Video playback is huge. If I play 24/96 Audio files from CD I have an Audiophile performance, when playing this kind of format from Music Video it's not (dynamics are gone) Playing around with Adaptive Volume does not do much good. So my request, please make sure that Stereo Streams from Video are handled without tweaking, I would like it pure, Audiophile....