INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: kstuart on February 12, 2013, 05:09:00 pm
-
MC18 sets the "Bit Depth" of files of file type:
AC3
DTS
MPC
to "32" which, of course, is incorrect. (It is also not editable in these file types and the raw tags view shows no bit depth setting at all.)
I only discovered this because I set my "High Resolution View" to "24 or greater" bit depth, since there are plans for 32 bit depth PCM files (just as there are plans for greater than 1080p video files).
As a workaround, I can, of course, set it to "equal to 24" - but it should be an easy fix (and might be evidence of some other bug in import).
-
MC18 sets the "Bit Depth" of files of file type:
AC3
DTS
MPC
to "32" which, of course, is incorrect.
There is no correct answer, and 32bit is what the decoder delivers.
I suppose it could say 'Lossy' instead, but it's a numeric field.
More here:
http://wiki.jriver.com/index.php/Audio_Bitdepth#Bitdepth_of_Lossy_Formats
-
There is no correct answer, and 32bit is what the decoder delivers.
I suppose it could say 'Lossy' instead, but it's a numeric field.
More here:
http://wiki.jriver.com/index.php/Audio_Bitdepth#Bitdepth_of_Lossy_Formats
There was an easy workaround, so it's not really important. However, the files don't have a third more bit-depth than 24-bit lossless files, and they won't have the same bit-depth as 32-bit lossless files (if and when those show up). So, it's "apples and onions" to write "32" into that tag - better would be to leave nothing at all.
-
I entered in DSP Studio the following settings:
1. Sample rates as specified > Output: "no change" (so all input sample rates are "not changed" in output)
2. Bitdepth: "source bitdepth".
No problem when I play an album in WAV format (16 bit, 44.1 Khz, 1401 kbps)
However when I play an album in WAV format (24 bit, 48.0 kHz, 2304 kbps) I get the following pop-up window, as attached.
When I click on "Change Settings and Continue playback", the Bitdepth is changed from "source bitdepth" to 16 bit in DSP Studio.
However, the display states it is 24 bit (I added in Customize Display > Play Mode Main > Status line: [Bitdepth] ).
Can you have a look at this please to correct? Thx
-
I entered in DSP Studio the following settings:
1. Sample rates as specified > Output: "no change" (so all input sample rates are "not changed" in output)
2. Bitdepth: "source bitdepth".
No problem when I play an album in WAV format (16 bit, 44.1 Khz, 1401 kbps)
However when I play an album in WAV format (24 bit, 48.0 kHz, 2304 kbps) I get the following pop-up window, as attached.
When I click on "Change Settings and Continue playback", the Bitdepth is changed from "source bitdepth" to 16 bit in DSP Studio.
However, the display states it is 24 bit (I added in Customize Display > Play Mode Main > Status line: [Bitdepth] ).
Can you have a look at this please to correct? Thx
This is normal, and just means your output hardware requires 16-bit.
[Bitdepth] shows the source file, not output. Use Audio Path to view the full output chain.
-
Thx, but I didn't experience this in MC17
-
Hi Matt,
when I used MC v17 (until yesterday) I had the bitdepth set at 24 bit. Exactly as described in here: http://wiki.jriver.com/index.php/Audio_Setup "Bitdepth-Select the highest bitdepth your hardware supports (usually 24-bit)."
I never encountered a problem (during some 15 months or so) with MC17.
I installed MC18 today, on the same hardware (Notebook Thinkpad W series, with 8 GB RAM, 250 GB Intel SSD, Windows 7 Enterprise 64-bit), and all of a sudden I get that pop-up window. I drives me nuts that pop-up window.
What has changed under the hood between MC 17 and MC 18?
-
http://wiki.jriver.com/index.php/Audio_Bitdepth
-
[Bitdepth] shows the source file, not output. Use Audio Path to view the full output chain.
" [Bitdepth] shows the source file, not output."
That's exactly why "32" is not right for a lossy file.
Your previous explanation was that 32 is what is being output.
The field is only an internal field, so it should be specified according to its uses, which are:
* To sort Views
* To display characteristics of the source file (such as in the Player Display)
Right now, neither of these work, because only 24-bit files like HDtracks files, are properly tagged. CDs ripped to lossless files have Bit Depth "blank" and the Player Display says " -bits ". Some lossy files say " 32-bits " when that is wrong in terms of the two possible uses of the field.
Again, it's also not a high priority.
-
I don't think Matt was saying the "output" was 32-bit (Matt correct me if I am wrong!). I believe he is saying the bitdepth field reports what the responsible decoder says it to be. If you think this is wrong you could try discussing with the author of the decoder (LAV, nevcairiel?). I can see it would be messy for Matt to start writing contorted logic to second guess what is reported by the responsible filter.
-
I don't think Matt was saying the "output" was 32-bit (Matt correct me if I am wrong!). I believe he is saying the bitdepth field reports what the responsible decoder says it to be. If you think this is wrong you could try discussing with the author of the decoder (LAV, nevcairiel?). I can see it would be messy for Matt to start writing contorted logic to second guess what is reported by the responsible filter.
By "source" one is presumably saying what was present before the decoder.
The whole point of the Bit-depth field is the source. In what way, it is not the source (i.e. whether it is "output" or "decoder" is irrelevant.
So, in the statement you are objecting to, change "output" to "not source".
-
No, what I'm saying is MC relies on the decoder filter to tell it the bit depth. I'm not sure but I don't think LAV passes a 32 bit integer on up the chain. I think it passes a floating point value (but I could be wrong on that).
-
No, what I'm saying is MC relies on the decoder filter to tell it the bit depth. I'm not sure but I don't think LAV passes a 32 bit integer on up the chain. I think it passes a floating point value (but I could be wrong on that).
As I said earlier, MC reports that .MPC files are "32-bit".
If I open an .MPC file with the tiny freeware utility MediaInfo, it reports:
Format : Musepack SV7
File size : 3.95 MiB
Duration : 3mn 29s
Overall bit rate : 158 Kbps
Audio
Format : Musepack SV7
Duration : 3mn 29s
Bit rate : 158 Kbps
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 3.95 MiB (100%)
Writing library : 0.00
It's open source and the source code is at:
http://mediainfo.sourceforge.net/en/Download/Source
-
So MediaInfo gets it wrong too, just in a different way. :)
This is not a very interesting and the longer it goes on the more I sound like i am nit-picking and a little pedantic! But I think you misunderstand what I am saying. I agree this field should ideally have something different in it, even if, as you say, it is not at all urgent.
I was just explaining that Matt was not contradicting himself. He was not saying it has the output bit depth, he was not even saying it has the internal bit depth he gets from the decoder, as you later seemed to think. He was explaining that MC currently fills that fields with what the decoder tells it is the source bit depth (at least that is my understanding!) . You can ask Matt to change so he overrides what he is told by the decoder in this specific case (but where does that end?) or the decoder could be changed to pass a different or null value. The latter is probably cleaner, but I guess it depends on who can be bothered!
-
So MediaInfo gets it wrong too, just in a different way. :)
In what way is MediaInfo getting it wrong ?
It reports that the MPC file is 16-bit, 44.1 khz, which is what it is, since it is just a CD run through lossy compression.
If MC18 is getting "32-bit" from the input plugin, then the input plugin is buggy - which apparently seems to be the source of a number of problems in MC18.
-
http://wiki.jriver.com/index.php/Audio_Bitdepth
This does NOT answer his question?