I get a message that the superblock cannot be read when trying to mount a music CD in an AppVm
Looking around out in general linux land, I found some claims that music CDs cannot be mounted due to lack of an actual file system, but a music player will just find them.
However the music players I tried have no way of specifying that the CD is at /dev/xvdi, (they’re looking in /dev/sr0 apparently) so I have no idea if this is true or not.
For sure, you should not mount a music cd (should show something though, like one file per track, but it’s not usable). You need to find a way to give the path the drive.
I discovered that Clementine lets you specify the drive. So after attaching to that AppVM, there’s a /dev/xvdi. Setting the drive to that, Clementine still wouldn’t read it. (Devices->you get a pane that says “removable–not mounted -double click to mount” which does nothing (except blink the light on the drive) when you do that. Right mousing brings up a menu with device properties and it shows the Device being at /dev/xvdi.
VLC, it turns out lets you specify a drive too, but you have to tell it you’re opening an Audio CD to see it (makes sense). (Media-> OpenDisc->select audio CD->then type /dev/xvdi on the Disc Device dropdown. This fails with “Your input can’t be opened: VLC is unable to open the MRL ‘cdda:///dev/xvdi’ Check the log [what log?] for details.”
I finally just decided to run VLC from the command line and it says:
cdda stream error: could not read TOCHDR
cdda stream error: cannot count tracks
Further info: running minimal debian template, and am using sys-usb. (Is there some key driver I could be missing? Or can it only work on sys-usb for some reason?)
Not only do audio CDs not have a filesystem that could really* be mounted, they don’t even have any data exposed at all for normal reading from the block device. For example, with a data CD or DVD creating a disk image is just cat /dev/sr0 >disc.img, but this won’t work with an audio CD. Software has to extract the PCM audio by talking to the drive over special CDDA ioctls. These are not available if the drive is forwarded as a block device.
Forward the drive as a USB device instead, or don’t forward it at all and use the audio player or ripping software (I like Whipper) directly in sys-usb or wherever the drive is. (Not ideal for security to do it in dom0 if it’s an SATA drive, but maybe not a problem in practice - assuming that the CD doesn’t also contain a data track, or some hypothetical exploit in the CDDA metadata.)
* Although there are some FUSE based virtual filesystems or file managers that do the audio extraction behind the scenes and present an audio CD as if was a collection of audio files in a mountable filesystem.
I booted Debian 12 live, and its default CD player is called Dragon.
Dragon would play the first track, but not let you skip ahead. However when the track ended, it would move on to the next track.
It seemed to be unaware how many tracks there were on the CD.
I’m going to try doing the same thing on my laptop, because I’m starting to get the impression that something about my desktop’s actual hardware is not quite right. Right now my impression is that Qubes seems to be part of my problem but not all of it.
Well, on my laptop that’s literally all it took. Thanks!
I figured it must be something simple–though some of the behavior I was noticing made me suspect I had hardware issues. But I saw the same things on my laptop when I attached the block device instead of the USB.
Attach the device, not the block. On my system that meant: Attach 0e8d:1887_Hitachi…<etc-who wants to type all that?> (Under USB devices) to the VM, not DVDRAM_GPS5EX70 (under block devices).
It showed up in my VM as /dev/sr0 and VLC had no trouble playing it. Of course now I need to install whipper on that VM so I can rip the CDs and put them in my FLAC library, but that’s a detail. Oh, and verify that works on my desktop.
[Side Note: Clementine also does rips, and it’s what I’d play the CD and music files on anyway.]