Print

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

[dtc]

When I burn a 24/192 file to a Audio CD it changes the sample rate to 44.1K, but it leaves the bit depth at 24. I do not see any place to change it to 16. It seems like if you are burning a CD it should automatically change the format to 16/44. I can convert the files to 16/44 and burn that, but that is an extra, unnecessary step.  It seems like burning an Audio CD ought to default to 16/44, not the the original bit depth/44. Am I missing a way to specify the bit depth?

[ferday]

Are you burning them as an archive or a playable redbook?

MC will not burn a playable audio CD at 24 bit (it's not even possible) but you can archive (FLAC or whatever) at any bitrate on a CD...

[dtc]

I wrote the CD as an Audio CD. When I play it back, the bit depth is reported as 24, the bitrate as 1440 and the sample rate as 44.1K. It may be a tagging issue, rather than what is on the CD.  Since the album, artist and track are the same as the 24/192 file, MC may be picking the bit depth information up from the other tag.

I just looked at Audio Path and it says the input bit depth is 16. But when I display bit depth in the header, it says 24. So, it may be something to do with where the bit depth information is coming from.

[ferday]

It's a tag or DSP output thing.  If the CD plays in a normal player it's definitely 16 bit!  I don't play CD's through JRiver but I'll try one and see what it says

[dtc]

A little more investigation. Using the CD I wrote, I see the following.

When playing a track from the CD I wrote, Audio Path shows input of 16/44 from Source CDA  but output of 24/44. For my audio device, I have bit depth to Automatic. So, that might be padding the output to 24 bits, although I do not see that on 14/44 files in my library.

When playing from the CD, the display of files in Playing Now clearly shows the first Filename as Audio CD/Track01.cda. So, it is reading the CD. However, the bit dept is set to 24, the sample rate is set to 192 KHz, and a field I defined (Media Sub Type Audio) is set to Vinyl. I changed the album name for the 24/192 file in the library, so album and album artist are different between that album and the CD. However, the Playing Now display list still shows the 24, 192K and Vinyl. The display (top of screen) however, shows 24/44, using bitdepth and samplerate.

In DSP Studio I have 192K set to downsample to 48K. So it is not the case that it is somehow playing the file from the library and not the CD. I also ejected the CD while it was playing and when MC got to the next track it closed the drive and read the next track form the CD.  

The Playing Now display, the top of screen display, and Audio Path seem to be mixing up tags between the CD and the file in the library.

Screenshot

[dtc]

I wounder if there is some cache issue here. Not sure how to check that. Any ideas?

[Awesome Donkey]

Creating a redbook audio CD will always convert the source files to 16-bit/44.1 kHz when burning.

The output to 24-bit suggests you might have the WASAPI bitdepth settings for your DAC/sound card set to 24-bit instead of automatic.

[dtc]

The output bit depth is set to Automatic. And, I do not see 24 bit output when playing my 16/44 CD rips for files in the library.

Take a close look at the first screen shot I posted. The bit depth and sample rate are all over the place if you look at the top display, the Audio Path display and the file list. Really bizarre. And how does it list a value for my user defined field when playing a CD? Something strange is going on here.

[RoderickGI]

Something unexpected, which probably shouldn't happen, but not so strange.

It looks like when you burned the CD MC retained the existing tags from the files, probably storing them in CD-Text format on the disc, including your custom tag "Media Sub Type Audio" tag, plus the original Sample Rate and Bit Depth. As you noted, it is reading the correct CDA file name, so it is reading the CD.

As MC saved those tags in CD-Text format on the CD, it is able to correctly read them back from the CD, and displays them for you, as per your screen shot.

The Audio Path correctly shows that the input file format is 16/44.1 The output format is actually 24/44.1, so that is what is displayed in the Audio Path, and in the display (top of screen).

As you have the output bit depth set to Automatic, it is probably your DAC that is telling MC to convert to 24bit. Hence the up-convert in the Audio Path. The only unexplained bit I can see is; why is the DAC selecting 24 Bit? Maybe for the files on the CD, MC is sending the tag information to the DAC, or its driver, so it selects that bit depth of the tag, which MC then up-converts to.  Actually I think when Bit Depth is set to automatic, MC asks the Device (your DAC) "Can you play this Bit Depth?", and the DAC says yes or no. If MC is incorrectly using the tag information to ask that question, then your DAC may be saying yes to 24 Bit, so MC up-converts. Someone who knows more about the internal goings on of MC would have to answer that one.

You don't see 24 bit output when playing 16/44 CD rips from files in the library, because when CDs are ripped to the hard drive and imported into MC, the Sample Rate and Bit Depth are correctly set in tags, which the DAC then honours as the correct settings.


I think the real issue here is: Why are the Sample Rate and Bit Depth tags written to the CD at their original values, instead of at the converted values?
There are probably discussions of this issue on the forum somewhere...

PS: The incorrect Bit Depth may actually be coming from a header written into the files, rather than the tags. I leave someone else to clarify that.
PPS: BTW, does a commercial 16/44.1 CD get up-converted when played in MC in your system? On my system they get up-converted to 32 Bit, as do CD rips on the drive! 

[dtc]

Thanks Roderick. Based on your explanation, I tried writing the same CD with Write CD Text not checked. I got  the same result. Your explanation may be correct, but it does seem strange that the tag information gets written to disk. I thought Write CD Text only applied to CD Title and Track Names. But, as I said, unchecking Write CD Text had no effect.

Interestingly, when I first loaded the CD, the Album Art was displayed for each track. However, as I play each track, the Album Art goes away. It is unlikely that the album art for each track in on the CD.

So I am still not sure where the meta data is coming from.

By the way, I looked up (Wikipedia) the parameters that are included in CD Text and bit depth and sample rate are not there, which is not surprising since they should always be the same.  Not sure how they would get written as CD Text.

[RoderickGI]

I suspect that while there is a standard for what can be written in CD Text, more could be written if a developer wanted to. There is quite a bit of space available. If MC wrote the CD Text, no doubt it could read it back. Unless one of the developers comments, we won't know.

I'm not sure about the Album Art. It seems to come and go a bit for me when I play music anyway. I always assumed it was getting it from the internet, and perhaps got small thumbnails when an Album was loaded, and then tried to get larger thumbnails when I played a track. Sometimes that is what happened.

Maybe you could find another CD Player application that shows metadata, and confirm how it plays, and what data is available, using the same hardware.

[dtc]

Thanks for your insights. This is more curiosity than a real necessity at this point. It does seem that if MC is writing the info to disk it is writing the wrong data, at least for bit depth and sample rate. Maybe I will just start a new thread specifically about what data is written to a CD when Write CD-Text is checked. The Wiki gives no additional detail other than Album Name and Track Names.

Thanks again.

[dtc]

I tried a different computer with a different drive. The album has never been in the second computer's MC library. A disk written with CD-Text turned off shows no album name or track names, as it should.  The one which I wrote with CD-Text turned on show album name, track names and shows bit depth of 16 and sample rate of 44.1K, just as it should. So, two things different on the second computer - different drive and album never on the computer. Seems to point again to some sort of cache or library issue.

This is not worth much more time, but there certainly seems like there is something strange when MC writes a 24/192 file to a CD.

[RoderickGI]

If time allows, it is always worth exploring anomalies. 

I doubt it would be a cache thing, as I am sure caches would be cleared regularly. If you reboot the machine where it happens, and restart MC, and it still happens, then MC must be deliberately trying to match the CD contents to the MC Library, and retrieving metadata from the library for display.

As you suggest, the difference could also be due to the different drive.

Anyway, it sounds like the disc with CD Text written to it should work fine in other devices, which is the outcome you really want.

[dtc]

I have tried rebooting and the tag values persisted, so memory caching is not what is happening. Rather it might be something within MC.  I was careless calling it caching. I was thinking it might be using some temporary file or it could be going back to the library itself. However, when I deleted the 24/192 files from the library, the tags form the CD persisted. So, it does not seem to just a  standard library lookup.

I need to do some more testing with my USB drive (the second drive) since I can move that from system to system. Then I will have a common point of reference. It could be a drive difference. CD-Text is not uniformly implemented on different drives.  The drive on the first system is internal.

I'll do some more testing when I have time.

I don't really need a disk with CD-Text. When I burn a disk, I just load it after burning, just to be sure it is OK. That is when I noticed the funny tags. So, this is all an academic quest at this point.

Thanks for your interest.