INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: AlexS on November 16, 2013, 10:32:35 pm
-
Media Center 19.0.74
Hello again :)
Tools -> Options -> Encoding - > FLAC encoder Settings.
Here we have a UI Bug for your tracker - Please change "quality" to "compression ratio" within the UI, currently this is misleading and wrong :) FLAC compression ratio does not improve quality as it is loss-less!
Also...
Please indicate which is high and which is low compression here (replacing the dropdown with a slidebar widget could help ), numbers mean nothing to the average Joe (although they still should be displayed if relevant).
Thanks
Alex
-
Media Center 19.0.74
Hello again :)
Tools -> Options -> Encoding - > FLAC encoder Settings.
Here we have a UI Bug for your tracker - Please change "quality" to "compression ratio" within the UI, currently this is misleading and wrong :) FLAC compression ratio does not improve quality as it is loss-less!
Also...
Please indicate which is high and which is low compression here (replacing the dropdown with a slidebar widget could help ), numbers mean nothing to the average Joe (although they still should be displayed if relevant).
Thanks
Alex
+1 This has bothered me for a long long time.
VP
-
+1
I think at one time the reference encoder from xiph.org used this kind of terminology for the -0 through -8 options. But they don't now (they call it compression level (http://xiph.org/flac/documentation_tools_flac.html)).
I agree it should be changed. It occasionally causes questions.
-
Look at the APE encoder in MC for an example of how I like lossless compression levels to be presented.
-
Look at the APE encoder in MC for an example of how I like lossless comrpession levels to be presented.
Excellent, should avoid the common misconception that compression in FLAC means lossy
-
Look at the APE encoder in MC for an example of how I like lossless comrpession levels to be presented.
I think this would be fine.
Or just remove the setting altogether. No one needs it anyway with modern hardware, and it just generates support questions. If people insist upon doing something odd with their Flac encoder, just use an external CLI encoder.
-
Settings are extremely important people want to be able to adjust their encoding when ripping. People need to know what it is gong on at that level when they are ripping 1000's of their CD's onto hard drive.
If the settings were be removed from the media player just because it "generates support questions" (you are joking I hope) I guess this reason would be justification enough to remove the whole media player or even remove Microsoft Windows ;).
-
Or just remove the setting altogether. No one needs it anyway with modern hardware, and it just generates support questions. If people insist upon doing something odd with their Flac encoder, just use an external CLI encoder.
I was under the impression that Level 5 was optimal for portable devices, which don't have much power to decode the audio. Is that not the case?
Obviously encoding speed is probably not going to be an issue if you were to use level 8 on a modern computer.
-
Settings are extremely important
Not that setting. It is essentially useless in the modern era. The file size differences are relatively small. It is like setting the ZIP compression level. Back when you were worried about differences in file sizes measured in K, okay, I'm with you. But...
The differences in encoding and decoding speed would be impossible to notice on any modern computer, and wouldn't make a difference on ay remotely competent hardware player either. The differences here are very slight.
Maybe, the only thing I can see it being useful for is if you are worried about bandwidth for streaming files. Even then, the differences are going to be pretty small. I'm skeptical about any substantial real world impact between 5 and 0 or 5 and 8.
But, in any case, I don't care if it is removed. But the wording/display should be changed.
-
Not that setting. It is essentially useless in the modern era. The file size differences are relatively small. It is like setting the ZIP compression level. Back when you were worried about differences in file sizes measured in K, okay, I'm with you. But...
The differences in encoding and decoding speed would be impossible to notice on any modern computer, and wouldn't make a difference on ay remotely competent hardware player either. The differences here are very slight.
Maybe, the only thing I can see it being useful for is if you are worried about bandwidth for streaming files. Even then, the differences are going to be pretty small. I'm skeptical about any substantial real world impact between 5 and 0 or 5 and 8.
But, in any case, I don't care if it is removed. But the wording/display should be changed.
You got me thinking and I just ran some tests to see what the compression difference might be. The difference between zero and eight is between 10 and 20% for me based on about twenty random albums converted. That's not that big of a deal on one album, but over an entire collection that's not irrelevant. For my collection that's between 50 and 100 gigs, and for some folks here I'm sure it's well into the hundreds of gigs. The difference between 5 and 8 seems pretty small, most of the difference appears to be between 0 and 5.
I agree that the decoding burden is probably trivial for most devices (I've never encountered a device that couldn't decode 8 ).
-
Okay, I retract my argument.
When you said that, I decided I too would run a test (because I've seen wildly differing and vague numbers in public tests I've seen). So, I just did two tests. I took a completely random 500 file sampling of my library (a mix of sources from audiobooks to classical to jazz to ABBA), and converted them to FLAC three times. Once to v6 (the default in MC) to start, and then from that "source" to FLAC -0 and FLAC -8.
I did this twice, with two sets of files.
On the first try, the resulting -8 files were 12.6% smaller than the -0 files.
On the second try, they were 18.4% smaller.
That's not totally insignificant with a large library, and was (even in the small case) a bit higher than I'd expected (which was between 4-9%), so I retract my argument. They're worth leaving in for a 10-20% difference, since it is supported already anyway.
Just relabel them.
-
I've used the maximum FLAC "compression" (try harder) factor forever. It costs me nothing, and a byte saved is a byte earned.
-
It seems I was mistaken - I had always been told that FLAC level 5 was the default because it was the best balance between encoding time and decoding speed.
It seems that this is not strictly true, and anything from 4-8 are so close that it really doesn't matter. (so you might as well use 8)
http://web.archive.org/web/20051016163102/http://people.ucsc.edu/~rswilson/flactest/index.html (http://web.archive.org/web/20051016163102/http://people.ucsc.edu/~rswilson/flactest/index.html)
-
It probably mattered a lot in 2000 when FLAC was created and the vast majority of folks were running 800 Mhz Pentium IIIs.
-
It probably mattered a lot in 2000 when FLAC was created and the vast majority of folks were running 800 Mhz Pentium IIIs.
Yeah, I'm sure it doesn't matter for computer-based playback at all, though I do wonder if it still impacts battery life on portable devices.
-
Yeah, I'm sure it doesn't matter for computer-based playback at all, though I do wonder if it still impacts battery life on portable devices.
I will point you to this report: https://xiph.org/flac/comparison.pdf
Notably, this figure:
(https://xiph.org/flac/images/all-tracks-decode.png)
There does seem to be a small penalty > preset -5 but in the scope of the other codecs, it is nearly insignificant.
The Rockbox guys might have empirical tests.
-
Next build:
Changed: Revised FLAC encoder settings to be more clear that all modes are lossless.
-
Thankyou for this... lovely.