Print

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

[Opawesome]

Hi,

I have recently installed JRiver Media Center. My problem is the following. My audio files have already an id3v2.3 tag with various informations that are  read correctly by the application. But I cannot get JRiver to read the field called "RATING" from the file (it displays a question mark).  ?

How can I achieve that please ? (Note that the values for my "RATING" tags are all integers from 1 to 5.)

Thanks for your help,

Opawesome

 

[Matt]

The rating in an ID3v2.3 tag should be in the POPM frame.  Media Center fully supports the POPM frame.

Are you saying you are using a non-standard frame instead?  What program created the tags?

Thanks.

[Opawesome]

Thanks for your answer.

I don't know what the POPM frame is.

The "RATING" field of my tags is either inexistent, either a value comprised between 1 and 5...

The tag was created either by mp3tag, either by foobar.

[Matt]

Could you email a sample file to matt at jriver dot com?

Thanks.

[Opawesome]

Done

Thanks.

[Matt]

Thanks for the file.

It uses TXXX(RATING) instead of the standard POPM.  I would report this as a bug to the authors of the software you used to tag the file.

It also has a track number of #59 (unlikely) and a peak level of 153% (impossible) in the tag.

Regardless, I have added support for TXXX(RATING) to our ID3v2 tag code.  You can use Library Tools > Update Library from Tags once you have build 89 or newer installed.

You might consider using Media Center for tagging in the future.

[Opawesome]

Thank you very much for your help.

I am going to follow your advice.

Btw, how did you determine that it was a TXXX and not POPM ? Just curious.

Regards,

Opawesome

[Matt]

Thank you very much for your help.

I am going to follow your advice.

Btw, how did you determine that it was a TXXX and not POPM ? Just curious.

Regards,

Opawesome

In Media Center, you can see a full tag dump on any file by:
Pick a file > Action Window > Tag > Click the first line

[Alex B]

...and a peak level of 153% (impossible) in the tag.

It's impossible only with integer bit depth lossless.

Decoding lossy files tends to create increased peaks that go over 100% if the floating point output is not truncated. This can happen especially with modern loud and compressed files (i.e. victims of the loudness war).  E.g. foobar and Winamp measure the decoded floating point PCM content and can produce such values. The pronounced peaks can be preserved by decoding to float and reducing the volume with Replay Gain before converting to integer bit depth.

Previously MC decoded to 16-bit and truncated the peaks, but I never bothered to raise an issue of that. It really doesn't matter if you preserve or truncate some peaks that have a duration of a few samples (often only one or two samples). No one can hear the difference and there is no way know which behavior actually produces output that is closer to the original.

However, when the new floating point MP3 decoder was introduced I was a bit surprised that MC didn't start to measure peak values that go over 100%, but perhaps the limitation is in the Replay Gain analyzer code.

I once posted some "loud" samples to Hydrogen Audio that create pronounced peaks when encoded to lossy and decoded to float:
http://www.hydrogenaudio.org/forums/index.php?showtopic=78476  (you can download the samples from the linked thread.)

One of the samples produces a peak value of 273% when it is encoded to MP3 (LAME -V5) and measured with foobar:




Here is a link to my other HA post, in which I explain how I experimented with trying to make the distorded "lossy" peaks audible:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=82112&view=findpost&p=713723

[Alex B]

The tag was created either by mp3tag, either by foobar.

Mp3tag supports also the POPM aka Popularimeter tag. You can rate a file with MC and check how the tag shows up in Mp3tag. Foobar doesn't support POPM. It can only create a custom TXXX tag.

[Matt]

It's impossible only with integer bit depth lossless.

Decoding lossy files tends to create increased peaks that go over 100% if the floating point output is not truncated. This can happen especially with modern loud and compressed files (i.e. victims of the loudness war).  E.g. foobar and Winamp measure the decoded floating point PCM content and can produce such values. The pronounced peaks can be preserved by decoding to float and reducing the volume with Replay Gain before converting to integer bit depth.

Previously MC decoded to 16-bit and truncated the peaks, but I never bothered to raise an issue of that. It really doesn't matter if you preserve or truncate some peaks that have a duration of a few samples (often only one or two samples). No one can hear the difference and there is no way know which behavior actually produces output that is closer to the original.

However, when the new floating point MP3 decoder was introduced I was a bit surprised that MC didn't start to measure peak values that go over 100%, but perhaps the limitation is in the Replay Gain analyzer code.

Interesting.

We currently cap at 100% in the MP3 decoder.

It would not be hard to remove the capping, but I'm not sure that would be better.  During playback, this would cause the clip protection in the audio chain to engage and turn the signal down.  Clip protection works on a moving average, so a single peak would get flat-lined and not attenuate the future signal too much.  But I'm still not sure if that's better.

What do you advise?

Thanks.

[Alex B]

I think it would be technically more correct to not "cap at 100%" and measure the real "extended peaks". Practically these occur with tracks that are very loud and replay gain usually compensates them by reducing the volume level more than the amount of the peak extension.

Though, if all tracks in a playlist are similarly loud and replay gain is set to "automatic correction" or replay gain is disabled the clip protection might occasionally kick in as you explained. I wonder if that could cause audible volume level fluctuation. How fast does it restore the original volume level if no further clipping occurs?

When replay gain is working you can always first reduce the overall track volume if needed to avoid clipping - as a correctly working replay gain implementation should do whenever the correction would mathematically cause clipping (i.e. when the resulting peak level would be over 100%).

Perhaps the actual real-time protection system could ignore very short peaks (e.g. less than 10 samples at 44.1 kHz) that do not extend over 150% or so. This could help to avoid the possible volume level fluctuation when replay gain is not active.

This phenomenon happens with all lossy formats. If you decide to remove the "100% cap" you should remove it also from AAC, Ogg Vorbis, etc.

[Matt]

Thanks Alex.

I updated our audio engine and analyzer so that a decoder could optionally output values greater than 100% and the analyzer and playback chain would support it nicely.

But I'm not sure if I want to change the MP3 decoder for v16.  I'm worried that the change will cause confusion.  The peak level of all of my recent MP3 files is between 101% - 125% with the cap removed in the decoder.

Anyone else have a strong opinion about this?