Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
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 signature.asc Description: PGP signature
Re: [OFFTOPIC] Filling the FAT (was: playing CDROM music questions)
On Tue, 9 Jan 2024 10:07:26 -0600 David Wright wrote: Hello David, >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. Yes, this is exactly what I experienced. So not the FAT at fault, but rather the 'ecosystem'. How time plays trick on one's memory. :-( -- Regards _ "Valid sig separator is {dash}{dash}{space}" / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" If you ain't sticking your knives in me, you will be eventually Monsoon - Robbie Williams pgp_96fXkiXqi.pgp Description: OpenPGP digital signature
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.
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
Re: playing CDROM music questions
On Tue, 9 Jan 2024 16:15:27 +0100 Nicolas George wrote: Hello Nicolas, >Pictures or it did not happen. Didn't bother because it appeared to be a well-understood phenomenon, based on my limited research. -- Regards _ "Valid sig separator is {dash}{dash}{space}" / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" I'm not here for your entertainment U & Ur Hand - P!nk pgphyuPBCFJB5.pgp Description: OpenPGP digital signature
Re: playing CDROM music questions
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 signature.asc Description: PGP signature
Re: playing CDROM music questions
On Tue, 9 Jan 2024 13:25:52 +0100 Nicolas George wrote: Hello Nicolas, >What are you talking about? FAT does not get “overloaded” by long >filenames. 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. -- Regards _ "Valid sig separator is {dash}{dash}{space}" / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" It's only bits of plastic, lines projected on the wall Keep It Clean - The Vibrators pgpY9oz8w1d5M.pgp Description: OpenPGP digital signature
Re: playing CDROM music questions
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 wy 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 signature.asc Description: PGP signature
Re: playing CDROM music questions
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 signature.asc Description: PGP signature
Re: playing CDROM music questions
On Mon, 8 Jan 2024 21:09:54 + Michael Kjörling <2695bd53d...@ewoof.net> wrote: Hello Michael, >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. Depends; I ended up buying three smaller sticks, because the limitations of the file system meant that the File Allocation Table got filled up wy before the larger capacity memory sticks did. I would point out that, since the sticks were bought for use in my car, reformatting to ext4 (for example) was not an option. 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. Of course, if you're going to reformat the sticks then the foregoing issues are moot. -- Regards _ "Valid sig separator is {dash}{dash}{space}" / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" I want those who get to know me to become admirers or my enemies Friend or Foe - Adam Ant pgpNCaahBYzGq.pgp Description: OpenPGP digital signature
Re: playing CDROM music questions
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
Re: playing CDROM music questions
> 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
Re: playing CDROM music questions
On 8 Jan 2024 15:49 -0500, from hai...@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?”
Re: playing CDROM music questions
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
Re: playing CDROM music questions
On Mon, Jan 08, 2024 at 04:32:37PM +, 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
Re: playing CDROM music questions
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
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
Re: playing CDROM music questions
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
Re: playing CDROM music questions
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.
Re: playing CDROM music questions
On 8 Jan 2024 11:00 -0500, from hai...@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?”
Re: playing CDROM music questions
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
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