INTERACT FORUM
More => Old Versions => Media Center 12 (Development Ended) => Topic started by: dcehl on March 05, 2008, 11:25:59 am
-
I don't understand why itunes can play all my songs at the same level while MC 12 cannot!
I love everything about MC - except this!
If there's anything that can be done for the next update - pleeeeeaaaase!
-
are all your songs analysed and have you enabled volume leveling?
-
Read about MC's "Replay Gain" system in the help file.
JRiver Media Center was one of the first adopters of Replay Gain, so it's been in the program for years. It's arguably the best system available for volume levelling.
-
As posted MC uses Replay Gain which has become the defacto standard for volume leveling and is rather good. iTunes like everything else chooses not to play well with others.
-
and that virtual sound you hear in the background is the virtual shrink wrap being taken torn of the virtual manuals.........
-
I need to add my 2 pesos by adding the replay gain works very well on my set-up.
Even on so-so DRM audio books that are analysed will play nice.
-
It does work very well. With that said, it might not be a bad idea to make it more easy to find and use.
When a user is used to WMP and iTunes, which both put the volume leveling function front and center in the options dialog, rather than in the DSP studio, then it can be a little challenging for the new user to even know this option exists. Even if they find it, there's really nothing there that informs them that they need to run the Analyze Audio tool before it will work. Both of WMP and iTunes automatically analyze the files if that option is turned on.
It's one of those features that, once you get get used to it, you can't really live without it. And if you're looking to switch from WMP or iTunes to MC, it might be a red mark if you can't find it, or worse, find it in DSP, turn it on, and then have it not work as expected.
Even a simple prompt that lets users know that Analyze Audio needs to be run before it can perform Volume Leveling, and a button that will automatically run that tool with all of their audio files loaded for them would be a huge useability improvement. But even then, I think this is a feature that needs to be more prominent somehow.
-
If there's anything that can be done for the next update - pleeeeeaaaase!
it depends on when you come back to read the answers and when the next update will be there.
-
Auto import can analyze audio. It runs at a very low priority and throttles itself so it never uses more than a few percent of the CPU.
-
Auto import can analyze audio. It runs at a very low priority and throttles itself so it never uses more than a few percent of the CPU.
Is that option on by default? I just had to dig around in options to try and find it, finally did, only to see that it was off. Honestly, I can't remember if I explicity turned it off, but I don't think I did. If it's off by default, then it doesn't really help a new user. Especially since, even if they find the option, it's not clear what it does or why it's a good thing.
-
As posted MC uses Replay Gain which has become the defacto standard for volume leveling and is rather good. iTunes like everything else chooses not to play well with others.
this made me laugh as replay gain is indeed standard, but the way MC has implemented is NOT standard.
It's an early version of the replay gain standard. MC does not recognise replay gain values added by other players (e.g. winamp, foobar), nor do these other players recognise the values calculated by MC
-
this made me laugh as replay gain is indeed standard, but the way MC has implemented is NOT standard.
It's an early version of the replay gain standard.
We weren't aware of any revision to the standard. Can you point to one?
We implemented the standard as originally proposed. Others apparently were more creative.
-
this made me laugh as replay gain is indeed standard, but the way MC has implemented is NOT standard.
It's an early version of the replay gain standard.
The proposed standard is about how the replay gain values are measured and how the playback correction system is handled. It doesn't suggest how applications should store the measured values. You must remember that JRiver had its system years before Winamp got official RG support or foobar2000 even existed.
MC does not recognise replay gain values added by other players (e.g. winamp, foobar), nor do these other players recognise the values calculated by MC
This is correct, though for example WMP does not save anything and iTunes uses a proprietary way for storing its "Sound Check" values.
IMO, JRiver could consider changing the tagging system to be compatible with the system that is used in Winamp, Foobar, Rockbox and some HW players/network clients. This would be the only reasonable option if the goal is to achieve better interoperability.
-
IMO, JRiver could consider changing the tagging system to be compatible with the system that is used in Winamp, Foobar, Rockbox and some HW players/network clients. This would be the only reasonable option if the goal is to achieve better interoperability.
I would very much support this. I use separate players and now I need to calculate twice.
Although the automatic audio analyses in recent builds has certainly made life much easier ;D
-
IMO, JRiver could consider changing the tagging system to be compatible with the system that is used in Winamp, Foobar, Rockbox and some HW players/network clients. This would be the only reasonable option if the goal is to achieve better interoperability.
I had MC analyse anything but my classical collection. It's something like 50K files to re-analyze, if MC would change the way RG works. If the transition should be just switching the current tags to other tags, I would say, keep it the way it is. Come on, if I ever would go checking on another player, I would not fiddle around with the RG values at first. And if I should consider the other player be better than MC, in the long run, i would gladly make this looooong recalculation of my library.
I would say, with a feature like RD, play it safe, let's not overrate interoperability. If I would have "some" music, I could go shopping for a new player now and then, which I did some years ago. MC is good, but there is still plenty of stuff, which should be made better, and discussed in the forum. Let's concentrate on things, that could be added, fixed, or made better. RG ist just fine.
My 2 kurus for this
-
I agree with ogurgey.
I don't think you should change anything. I don't care about interoperability and I definately do not want to reanalyze my library. This is a really big deal for those of us with large libraries. It would take a very long time, and it would touch every file with the inherent risks this creates.
-
I agree with ogurgey.
I don't think you should change anything. I don't care about interoperability and I definately do not want to reanalyze my library. This is a really big deal for those of us with large libraries. It would take a very long time, and it would touch every file with the inherent risks this creates.
You wouldn't need to re-analyse your files, MC could just copy the RP values from one tag to another for files already analysed and write RG values to different tags for new files.
-
I agree with ogurgey.
I don't care about interoperability and I definately do not want to reanalyze my library.
Some of us do. It'd be a huge bonus to me to have the RG info from MC work in my mp3 player and in SlimServer. One could maybe do it as gummbah proposed or have an option, old and new type of rg?
-
Yes, an option to choose between old and new rg would be fine.
Just to clarify my concern...
I am very fussy about my library. I analyse, tag, rename, and do a manual quality control check on every file before commiting it to my library. If RG changes such that tags must be rewritten then every file in my library will be modified and there will be no humanly possible way for me to be certain that errors were not inadvertently introduced.
-
The proposed standard is about how the replay gain values are measured and how the playback correction system is handled. It doesn't suggest how applications should store the measured values. You must remember that JRiver had its system years before Winamp got official RG support or foobar2000 even existed.
This is correct, though for example WMP does not save anything and iTunes uses a proprietary way for storing its "Sound Check" values.
IMO, JRiver could consider changing the tagging system to be compatible with the system that is used in Winamp, Foobar, Rockbox and some HW players/network clients. This would be the only reasonable option if the goal is to achieve better interoperability.
Does anybody know what the standard tag is? I did some looking and found three id3 "custom" tags for storing replay gain; RGAD XRVA & RVA2. The first is supposed to be obsolete, the second experimental, and the third is supposedly for v.4.
Any details about the system for storing replay gain that everyone uses would be greatly appreciated.
Thanks,
JimN
-
Does anybody know what the standard tag is? I did some looking and found three id3 "custom" tags for storing replay gain; RGAD XRVA & RVA2. The first is supposed to be obsolete, the second experimental, and the third is supposedly for v.4.
Any details about the system for storing replay gain that everyone uses would be greatly appreciated.
Thanks,
JimN
There are no official standards. From the top of my head I can list at least five different methods for storing replaygain or other volume leveling info:
- foobar2000/Winamp/Rockbox/FLAC (calculated by the encoder)/etc
- LAME (calculated by the encoder, stored in the LAME info tag)
- JRiver
- MP3Gain (uses APE tags instead of ID3v2x)
- iTunes
The foobar2000/Winamp/Rockbox/FLAC/etc system is the de facto standard that is accepted by many developers.
I have outlined what would be needed to convert the JRiver tags in this post:
http://yabb.jriver.com/interact/index.php?topic=38695.msg263284#msg263284
-
The foobar2000/Winamp/Rockbox/FLAC/etc system is the de facto standard that is accepted by many developers.
I have outlined what would be needed to convert the JRiver tags in this post:
http://yabb.jriver.com/interact/index.php?topic=38695.msg263284#msg263284
I implemented this standard for track replay gain and peak. In the next build.
JimN
-
I implemented this standard for track replay gain and peak. In the next build.
JimN
Thanks. This is very interesting. I suppose we can discuss about the changes in the beta forum before the public release.
-
I implemented this standard for track replay gain and peak. In the next build.
JimN
This is really exciting! Looking forward to the release.
Cheers and thanks. I love the way you interact with your users.
Never seen that before.
-
Please use this thread (http://yabb.jriver.com/interact/index.php?topic=45711.0)to continue the discussion.