Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265663 > unrolled thread

playing CDROM music questions

Back to article view | Back to linux.debian.user

Contents

  playing CDROM music questions Haines Brown <haines@histomat.net> - 2024-01-08 17:20 +0100
    Re: playing CDROM music questions Nicolas George <george@nsup.org> - 2024-01-08 17:30 +0100
      Re: playing CDROM music questions Haines Brown <haines@histomat.net> - 2024-01-08 22:00 +0100
        Re: playing CDROM music questions Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-01-08 22:20 +0100
          Re: playing CDROM music questions Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-09 01:50 +0100
          Re: playing CDROM music questions Nicolas George <george@nsup.org> - 2024-01-09 13:30 +0100
            Re: playing CDROM music questions Nicolas George <george@nsup.org> - 2024-01-09 16:20 +0100
            Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-09 17:00 +0100
              Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions) David Wright <deblis@lionunicorn.co.uk> - 2024-01-09 17:10 +0100
                Re: [OFFTOPIC] Filling the FAT Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-09 21:40 +0100
                  Re: [OFFTOPIC] Filling the FAT David Wright <deblis@lionunicorn.co.uk> - 2024-01-10 01:40 +0100
              Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions) <tomas@tuxteam.de> - 2024-01-09 18:20 +0100
        Re: playing CDROM music questions "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-09 03:50 +0100
        Re: playing CDROM music questions Nicolas George <george@nsup.org> - 2024-01-09 13:30 +0100
    Re: playing CDROM music questions Michel Verdier <mv524@free.fr> - 2024-01-08 17:40 +0100
      Re: playing CDROM music questions Haines Brown <haines@histomat.net> - 2024-01-08 22:10 +0100
    Re: playing CDROM music questions Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-01-08 17:40 +0100
      Re: playing CDROM music questions Nicolas George <george@nsup.org> - 2024-01-08 17:50 +0100
        CD-DA sector addressing, was Re: playing CDROM music questions "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-08 20:10 +0100
      Re: playing CDROM music questions Haines Brown <haines@histomat.net> - 2024-01-08 22:10 +0100

#265663 — playing CDROM music questions

I wish to play cdrom music discs from an exterrnal USB CDROM drive. It 
is the Rioddas drive recomended for linux.

I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
the cdrive. But I can play cds without mounting. Wny is mounting 
sometimes recommended?

I wanted to use aplay to play music on cdrom, but have concluded 
it cannot be done in any straightforward way. Why not?

The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
my system it relies on alsa. However, about every 15 seconds the the 
process stops for about one second ane the drive LED flashes on. In 
the mplayer configuration I do D not see anything about buffer size.

To simplify my life, I created a ~/scripts/play file. It is in my 
PATH. The file has this content:

  #!/bin/sh

  mplayer /dev/sr0 cdda://

  exit 0

But the $ play command only returns the aplay -help info. Why won't 
the script work?

-- 

     Haines Brown 

[toc] | [next] | [standalone]

#265664

Haines Brown (12024-01-08):
> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 

Please do not remove the protocol part from the URL, it makes
auto-detection and copy-pasting more annoying.

> the cdrive.

I do not see this page suggesting to mount audio CDs. Audio CDs do not
contain a files system, nor do they contain the synchronization
information necessary for a reliable read.

There is a hack in the kernel to mount them and present audio track as
PCM files but it is a hack, I do not know if it is enabled by default
and I do not recommend too use it.

>	      But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

Either people are wrong to recommend it or you are mistaken in thinking
they recommend it.

> I wanted to use aplay to play music on cdrom, but have concluded 
> it cannot be done in any straightforward way. Why not?

Because aplay requires the data to be available as a plain stream of
octets and the kernel does not provide that interface for audio CDs.

> The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
> my system it relies on alsa. However, about every 15 seconds the the 
> process stops for about one second ane the drive LED flashes on. In 
> the mplayer configuration I do D not see anything about buffer size.

Search for “cache” in the man page.

> To simplify my life, I created a ~/scripts/play file. It is in my 
> PATH. The file has this content:
> 
>   #!/bin/sh
> 
>   mplayer /dev/sr0 cdda://
> 
>   exit 0
> 
> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

You forgot the “-cdrom-device” option. And judging from what you are
saying you need to learn how $PATH works.

But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
of trouble: just run cdparanoia -B then opusenc and put back the audio
CD at the back of the shelf where it belongs.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#265674

On Mon, Jan 08, 2024 at 05:23:34PM +0100, Nicolas George wrote:
> Haines Brown (12024-01-08):
> > I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 

Understood about not mounting CDROM disks. Confused music with data 
disks

> > The mplayer command $ mplayer -cdrom-device /dev/sr0 cdda:// works. On 
> > my system it relies on alsa. However, about every 15 seconds the the 
> > process stops for about one second ane the drive LED flashes on. In 
> > the mplayer configuration I do D not see anything about buffer size.
> 
> Search for “cache” in the man page.

Thanks! That solved my problem. I find cache (enable/disable) and 
cache size (cache). 

In /etc/mplayer/mplayer.conf there is a cache section. I changed the 
line

	# cache = 8192
 
  to 
	
	cache = 16384

and that seems to  have fixed the buffer problem.
 
> > To simplify my life, I created a ~/scripts/play file. It is in my 
> > PATH. The file has this content:
> > 
> >   #!/bin/sh
> > 
> >   mplayer /dev/sr0 cdda://
> > 
> >   exit 0
> > 
> > But the $ play command only returns the aplay -help info. Why won't 
> > the script work?
> 
> You forgot the “-cdrom-device” option. And judging from what you are
> saying you need to learn how $PATH works.

The scripts folder is in my path. I holds many commands I regularly 
use.

Turns out that the "play" command was earlier taken by another 
application. So I changed the command from play to Play, and now it 
works without the cache problem. The Play command is:

	mplayer /dev/sr0 cdda://

The option -cdrom-device is default and so is optional. Mplayer works 
fine without it. 

> But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
> of trouble: just run cdparanoia -B then opusenc and put back the audio
> CD at the back of the shelf where it belongs.

where can find an inexpensive drive to hold about 1000 cds and find 
the time do all the converting? ㋡ 

> 
> Regards,
> 
> -- 
>   Nicolas George
> 

-- 

     Haines Brown 

[toc] | [prev] | [next] | [standalone]

#265677

On 8 Jan 2024 15:49 -0500, from haines@histomat.net (Haines Brown):
>> But unless you cannot spare 60 megaoctets somewhere, save yourself a lot
>> of trouble: just run cdparanoia -B then opusenc and put back the audio
>> CD at the back of the shelf where it belongs.
> 
> where can find an inexpensive drive to hold about 1000 cds and find 
> the time do all the converting? ㋡ 

I don't know what you consider inexpensive, but even uncompressed,
1000 CDs is about 700-800 GB. (FLAC will approximately halve that; MP3
at close to CD quality will reduce it to about 1/10.) Just a quick
check, Amazon lists a USB3 1TB Seagate HDD for $58 plus shipping,
though I've heard some horror stories about buying storage media from
Amazon as of late. There are certainly other options available, both
in terms of hardware, suppliers and resellers. Also 1 TB is
sufficiently small that the next step up isn't appreciably more
expensive; a similar 2 TB model lists for $70, for example.

Alternatively, they also offer SanDisk SDXC 128 GB memory cards at $14
a piece. One such will easily hold 1000 CDs at near-CD quality MP3.

The time to physically go through all those CDs, now that's a slightly
different issue.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#265682

> The time to physically go through all those CDs, now that's a slightly
> different issue.

Once you've setup your "rip" tool (I used mostly `grip` back then,
not sure what's still maintained, maybe `abcde`?), it's a small matter
of putting the next CD in the drive when the previous one is ejected
(i.e. every 10 minutes or so).
I did it while doing other things on my computer.

The hardest part is labeling the resulting audio files: while some CDs
have good data in CDDB and friends (so the rip tool can do a good job
auto-labeling), not all do, sadly.


        Stefan

[toc] | [prev] | [next] | [standalone]

#265705

[Multipart message — attachments visible in raw view] — view raw

Brad Rogers (12024-01-09):
> Depends;  I ended up buying three smaller sticks, because the
> limitations of the file system meant that the File Allocation Table
> got filled up waaaay before the larger capacity memory sticks did.

The USB sticks we were discussing in this thread are way below the
limitations of FAT.

> Even with the smaller sticks, I had to use all upper case, and stick to
> 8.3 names for the files, otherwise the FAT still got overloaded.

What are you talking about? FAT does not get “overloaded” by long
filenames.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#265709

[Multipart message — attachments visible in raw view] — view raw

Brad Rogers (12024-01-09):
> Seen it happen;  Long filenames, mixed case, and files saved at the
> beginning of a session of copying multiple files would be lost because
> the FAT was filled, and overwritten from the start by files added later
> in the session.
> 
> We are talking in excess of 20,000 (not difficult to achieve with
> over 1000 CDs to rip) files here, mixed case, and long file names, all.

Pictures or it did not happen.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#265711 — Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

>>What are you talking about? FAT does not get “overloaded” by long
>>filenames.
> Seen it happen;

I have serious doubts about the "it".

> Long filenames, mixed case, and files saved at the beginning of
> a session of copying multiple files would be lost because the FAT was
> filled, and overwritten from the start by files added later in
> the session.

The FAT doesn't contain file names.  It has a fixed size and contains
one "word" per block in the partition, and that word indicates simply if
the corresponding block is free or not, and if not, what is the next
block of the corresponding "file" (where that "file" may be also
something like a directory).

The FAT doesn't get filled/emptied: it has the same size whether the
partition is empty or full, because the partition contains a fixed
number of blocks.

So, I don't doubt you have seen what you have seen, but whatever you
have seen was not due to "the FAT was filled".


        Stefan

[toc] | [prev] | [next] | [standalone]

#265712 — Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

On Tue 09 Jan 2024 at 10:57:29 (-0500), Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
> 
> I have serious doubts about the "it".
> 
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
> 
> The FAT doesn't contain file names.  It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
> 
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
> 
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".

I would agree with that. I don't follow the evolution of FAT,
but what seems most likely is that the root directory filled up.
The size of that is fixed when formatted, at least up to FAT16.
Long filenames will eat it up more quickly still. Create
subdirectories and the problem goes away.

With large sticks nowadays, the problem revolves more around the
/time/ it takes to read huge subdirectories. I don't know what
the limitations on FAT32 root directory sizes are.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#265729 — Re: [OFFTOPIC] Filling the FAT

David Wright [2024-01-09 10:07:26] wrote:
> but what seems most likely is that the root directory filled up.
> The size of that is fixed when formatted, at least up to FAT16.
> Long filenames will eat it up more quickly still.

Long file names are actually kept in a (hidden) files, so they don't eat
up the directory space any more than normal file names.
(I'm talking about VFAT, here, which is the standard way to add long
file names to FAT)

tomas@tuxteam.de [2024-01-09 18:14:47] wrote:
> The LFS layer on top of FAT does have some limitations: "Because the
> FAT LFN implementation is layered atop an older, more limited naming
> system, there are inevitable complications, such as if an attempt is
> made to create too many files with the same first six letters" [1].

So indeed if you have too many names in the same directory you're likely
to bump into problems (you'd hope it would signal an error rather than
silent corruption, but ...).

Of course, it's usually easy to work around the problem by spreading the
files within several directory.  For ripped CDs, I'd recommend one
directory per CD (I use 2 levels: every artist gets a directory and in
that directory every album gets its own subdirectory).


        Stefan

[toc] | [prev] | [next] | [standalone]

#265734 — Re: [OFFTOPIC] Filling the FAT

On Tue 09 Jan 2024 at 15:30:49 (-0500), Stefan Monnier wrote:
> David Wright [2024-01-09 10:07:26] wrote:
> > but what seems most likely is that the root directory filled up.
> > The size of that is fixed when formatted, at least up to FAT16.
> > Long filenames will eat it up more quickly still.
> 
> Long file names are actually kept in a (hidden) files, so they don't eat
> up the directory space any more than normal file names.
> (I'm talking about VFAT, here, which is the standard way to add long
> file names to FAT)

(I find the term "vfat" rather ambiguous.) Here is the output from
a USB stick that I used on Boxing Day to pass a copy of a Christmas
Day video (a flaming pudding) to a Windows computer.

  $ grep _FS_ /run/udev/data/b8\:17 
  E:ID_FS_LABEL=china256
  E:ID_FS_LABEL_ENC=china256
  E:ID_FS_UUID=F8FA-4A08
  E:ID_FS_UUID_ENC=F8FA-4A08
  E:ID_FS_VERSION=FAT16
  E:ID_FS_TYPE=vfat
  E:ID_FS_USAGE=filesystem
  $ 

  $ sudo fdisk -l /dev/sdb
  Disk /dev/sdb: 246 MiB, 257949696 bytes, 503808 sectors
  Disk model: DataTraveler 2.0
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: dos
  Disk identifier: 0xefc20858

  Device     Boot Start    End Sectors  Size Id Type
  /dev/sdb1  *       63 503807  503745  246M  e W95 FAT16 (LBA)
  $ 

  $ ls -lR /media/china256/
  /media/china256/:
  total 78488
  -rw-r----- 1 auser auser 80357062 Dec 25 18:35  Looong-Filename.LOONG-EXT
  drwxr-x--- 2 auser auser     8192 Dec 26 10:18 'System Volume Information'

  '/media/china256/System Volume Information':
  total 16
  -rw-r----- 1 auser auser 76 Dec 26 10:18 IndexerVolumeGuid
  -rw-r----- 1 auser auser 12 Dec 26 10:18 WPSettings.dat
  $ 

The windows computer vomited those Boxing Day entries onto the stick.
Here's the pertinent bit:

  # hexdump -C /dev/sdb | grep -B2 -A14 -m1 china256
  0001c2b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  00026c00  63 68 69 6e 61 32 35 36  20 20 20 08 00 00 00 00  |china256   .....|
  00026c10  00 00 00 00 00 00 c7 00  af 4e 00 00 00 00 00 00  |.........N......|
  00026c20  42 6d 00 65 00 2e 00 4c  00 4f 00 0f 00 0e 4f 00  |Bm.e...L.O....O.|
  00026c30  4e 00 47 00 2d 00 45 00  58 00 00 00 54 00 00 00  |N.G.-.E.X...T...|
  00026c40  01 4c 00 6f 00 6f 00 6f  00 6e 00 0f 00 0e 67 00  |.L.o.o.o.n....g.|
  00026c50  2d 00 46 00 69 00 6c 00  65 00 00 00 6e 00 61 00  |-.F.i.l.e...n.a.|
  00026c60  4c 4f 4f 4f 4e 47 7e 31  4c 4f 4f 20 00 14 ef ae  |LOOONG~1LOO ....|
  00026c70  29 58 9a 57 00 00 7c 04  9a 57 03 00 c6 26 ca 04  |)X.W..|..W...&..|
  00026c80  42 20 00 49 00 6e 00 66  00 6f 00 0f 00 72 72 00  |B .I.n.f.o...rr.|
  00026c90  6d 00 61 00 74 00 69 00  6f 00 00 00 6e 00 00 00  |m.a.t.i.o...n...|
  00026ca0  01 53 00 79 00 73 00 74  00 65 00 0f 00 72 6d 00  |.S.y.s.t.e...rm.|
  00026cb0  20 00 56 00 6f 00 6c 00  75 00 00 00 6d 00 65 00  | .V.o.l.u...m.e.|
  00026cc0  53 59 53 54 45 4d 7e 31  20 20 20 16 00 9e 4a 82  |SYSTEM~1   ...J.|
  00026cd0  9a 57 9a 57 00 00 4b 82  9a 57 02 00 00 00 00 00  |.W.W..K..W......|
  00026ce0  e5 46 55 50 44 4f 7e 31  44 45 42 20 00 50 04 9e  |.FUPDO~1DEB .P..|
  # 

As you can see, the LOOONG~1LOO entry is preceded by two extra entries
(in reverse order) containing a UCS-2 version of Looong-Filename.LOONG-EXT,
mixed in with various other bytes.

The System Volume Information follows in the same way, and then the
start of what looks like a deleted .deb entry, probably ifupdown.

> tomas@tuxteam.de [2024-01-09 18:14:47] wrote:
> > The LFS layer on top of FAT does have some limitations: "Because the
> > FAT LFN implementation is layered atop an older, more limited naming
> > system, there are inevitable complications, such as if an attempt is
> > made to create too many files with the same first six letters" [1].
> 
> So indeed if you have too many names in the same directory you're likely
> to bump into problems (you'd hope it would signal an error rather than
> silent corruption, but ...).

Whether you run out of directory entries or unique filenames first
will depend on the use case. The normal limit for the top-level
FAT directory is 512 entries, and I've just checked this by touching
505 empty files (names are A<4 digits>) in the directory above.
Adding two 3-entry filenames and the compatibility volume label
makes 512 entries.

OTOH, there can be ~100 filenames that start with the same five
characters, so storing all your Bach cantatas as CantataBWV1,
CantataBWV2, etc would presumably fail.

> Of course, it's usually easy to work around the problem by spreading the
> files within several directory.  For ripped CDs, I'd recommend one
> directory per CD (I use 2 levels: every artist gets a directory and in
> that directory every album gets its own subdirectory).

Our car can certainly handle subdirectories: currently our "car stick"
has 1421 .m4a files in 60 subdirectories. (OTOH it gets screwed up by
the U3 USB stick that we somehow came by.) But it's no guarantee that
every device can handle them, particularly those of a certain age.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#265717 — Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 09, 2024 at 10:57:29AM -0500, Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
> 
> I have serious doubts about the "it".
> 
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of copying multiple files would be lost because the FAT was
> > filled, and overwritten from the start by files added later in
> > the session.
> 
> The FAT doesn't contain file names.  It has a fixed size and contains
> one "word" per block in the partition, and that word indicates simply if
> the corresponding block is free or not, and if not, what is the next
> block of the corresponding "file" (where that "file" may be also
> something like a directory).
> 
> The FAT doesn't get filled/emptied: it has the same size whether the
> partition is empty or full, because the partition contains a fixed
> number of blocks.
> 
> So, I don't doubt you have seen what you have seen, but whatever you
> have seen was not due to "the FAT was filled".

I gues we are talking about VFAT, otherwise the "long" filename doesn't
make much sense.

The LFS layer on top of FAT does have some limitations: "Because the
FAT LFN implementation is layered atop an older, more limited naming
system, there are inevitable complications, such as if an attempt is
made to create too many files with the same first six letters" [1].

Given the baroque construction of that thing (only Microsoft could've
come up with such a monster), I'd not be surprised if there were known
bugs kept around for backward compatibility.

So perhaps what Brad observed was a name collision in the underlying
("bare") FAT file system (I've seen that back then, Windows 3.1) or
some other strange inhabitant of that code biotope.

Cheers

[1] https://en.wikipedia.org/wiki/Long_filename
-- 
t

[toc] | [prev] | [next] | [standalone]

#265689

On Monday 08 January 2024 03:49:17 pm Haines Brown wrote:
> where can find an inexpensive drive to hold about 1000 cds and find 
> the time do all the converting? ㋡ 
 
The 4TB drive in my server has about 77GB roughly holding a similar amount of stuff.  The time was over a rather lengthy period of time,  not all done at once.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#265706

[Multipart message — attachments visible in raw view] — view raw

Haines Brown (12024-01-08):
> and that seems to  have fixed the buffer problem.

Nice.

> The scripts folder is in my path. I holds many commands I regularly 
> use.
> 
> Turns out that the "play" command was earlier taken by another 
> application. So I changed the command from play to Play, and now it 
> works without the cache problem. The Play command is:

I personally choose to have both a scripts directory not in my $PATH,
where I call the commands with explicit path, and a ~/bin directory at
the beginning of my path.

> 	mplayer /dev/sr0 cdda://
> 
> The option -cdrom-device is default and so is optional. Mplayer works 
> fine without it. 

The option “-cdrom-device” cannot be the default because it is not
self-contained. It is possible “-cdrom-device /dev/sr0” is the default
on your system. But if you give the argument to the option without the
option, then I think that if you read mplayer's output more carefull you
will find it tried to play it as a file, failed and skipped it.

> where can find an inexpensive drive to hold about 1000 cds and find 

As was pointed out, we are looking at between 60 giga-octets
lossy-but-transparent and 500 giga-octets lossless, so between a
mid-sized USB stick and a small external hard drive.

Whether you consider it inexpensive is your estimate.

> the time do all the converting? ㋡ 

Eh, this one is obvious: while you listen to them.

You are writing a script to play your CD: just make the script a little
more powerful and it will rip them at the same time.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#265665

On 2024-01-08, Haines Brown wrote:

> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
> the cdrive. But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

It talks about mounting "data" CD. Audio CD cannot be mounted and are
accessed by device (like /dev/sr0).

> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

You fumble on another "play" program. Try "type -a play" to
confirm. Then just rename your script.

[toc] | [prev] | [next] | [standalone]

#265676

On Mon, Jan 08, 2024 at 05:37:00PM +0100, Michel Verdier wrote:
> On 2024-01-08, Haines Brown wrote:

> > But the $ play command only returns the aplay -help info. Why won't 
> > the script work?
> 
> You fumble on another "play" program. Try "type -a play" to
> confirm. Then just rename your script.

You are correct. Renaming the file did the trick.
 
-- 

     Haines Brown 

[toc] | [prev] | [next] | [standalone]

#265666

On 8 Jan 2024 11:00 -0500, from haines@histomat.net (Haines Brown):
> I find that often (such as wiki.debian.org/CDDVD) I'm told to mount 
> the cdrive. But I can play cds without mounting. Wny is mounting 
> sometimes recommended?

You mount a file system. Audio CDs (that is, CD-DA disks) do not hold
file systems, so they aren't mounted in the typical sense.

Note that while CD-DA disks are technically CD-ROM disks (compact disk
read only media), in typical usage "CD-ROM" is taken to mean a CD
which contains _data organized as files within a file system_, often
an ISO-9660 file system typically with extensions (Rockridge, Juliet,
...).


> I wanted to use aplay to play music on cdrom, but have concluded
> it cannot be done in any straightforward way. Why not?

Likely simply because nobody has implemented that. Software to play
audio CDs exists aplenty; is there any particular reason why you want
to use specifically aplay to do it?


> However, about every 15 seconds the the
> process stops for about one second ane the drive LED flashes on.

I suspect this is because of insufficient read-ahead or insufficient
bandwidth, as you seems to assume to based on your comment on buffer
size. You might be able to use --cache=yes to improve matters.

Another option is to copy the CD audio to the computer using some tool
designed for that, and then play the copy. I suggest trying cdparanoia
for this, as it has excellent handling of poor read quality or buffer
underrun/overrun.


> To simplify my life, I created a ~/scripts/play file. It is in my 
> PATH. The file has this content:
> 
>   #!/bin/sh
> 
>   mplayer /dev/sr0 cdda://
> 
>   exit 0
> 
> But the $ play command only returns the aplay -help info. Why won't 
> the script work?

Check the output of: type play

Most likely something else named play comes earlier in your $PATH.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#265667

Michael Kjörling (12024-01-08):
> Note that while CD-DA disks are technically CD-ROM disks (compact disk
> read only media), in typical usage "CD-ROM" is taken to mean a CD
> which contains _data organized as files within a file system_, often
> an ISO-9660 file system typically with extensions (Rockridge, Juliet,
> ...).

It is worse than that: compared to data CDs, audio CDs lack one layer of
error-correcting code and the synchronization necessary to tell the
position of a particular sector.

This is why tools like cdparanoia exist: between one read and the next
they seek back a few sectors and check that the overlap matches.

But on the other hand, an audio CD can contain up to 807 mega-octets of
audio, compared to only 703 for a data CD.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#265670 — CD-DA sector addressing, was Re: playing CDROM music questions

Hi,

i cannot contribute much to the practical issues with playing music.
But i'd like to clarify technical properties of CD-DA media:

Nicolas George wrote:
> compared to data CDs, audio CDs lack one layer of error-correcting code

True.

Another drawback is that CD-DA sectors cannot be read by the usual SCSI
commands for hard disk reading, but only by the special command READ CD.

> and [lack] the synchronization necessary to tell the
> position of a particular sector.

Not true. It is possible to read CD-DA with sector granularity.

Random addressing may be somewhat cumbersome for the drive, because the
exact sector address is part of the low level data of the sector.
See MMC-5 4.2.3.5.2 "Mode-1 Q" for how it is implemented on medium and
6.20 "READ CD Command" for how it is to be operated by software of the
hosting computer.

> This is why tools like cdparanoia exist: between one read and the next
> they seek back a few sectors and check that the overlap matches.

If ever it is the drive's firmware which has to guess the position and
then to pick the sectors with the desired address in Mode-1 Q (or in a
neighbor if one of the 10% sectors without Mode-1 Q is desired).

The main reason for specialized CD readers like cdparanoia is rather in
the fact that data readers like mount(8) want to use the general SCSI disk
read commands. There are more reasons, as the man page of cdparanoia
indicates, including workarounds for bugs of antique drives.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#265675

On Mon, Jan 08, 2024 at 04:32:37PM +0000, Michael Kjörling wrote:

> I suspect this is because of insufficient read-ahead or insufficient
> bandwidth, as you seems to assume to based on your comment on buffer
> size. You might be able to use --cache=yes to improve matters.

To judge by the man mplayer, I suspect the line in the config file 
would be cache = enable

Although all the cache lines in /etc/mplayer/mplayer.conf are 
commented out, simply replacing the line # cache = 8192 with the line 
cache = 16384 solved the buffer problem. Is cache thereby enabled? 

> Check the output of: type play
> 
> Most likely something else named play comes earlier in your $PATH.

You are correct. Solved the problem by changing play to Play.

Thank you.
 

> Michael Kjörling                     🔗 https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”


-- 

     Haines Brown 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web