Auto Ripping - doesn't start, not always available #46
Comments
|
Thank you for reporting this! The second issue (automatization options not being available after creating a new configuration) is fixed now with the 7e33167 commit. As for the first issue, there have been some issues with this feature on Windows in the past (not only with the 1.1 development versions, but also with 1.0.x). In some cases, Windows just does not seem to be sending the media arrival message to all applications. Though it's strange that it works for you with fre:ac 1.0.32. If you have been using the fre:ac 1.1 64 bit version, could you try if the 32 bit version behaves better? Also, is there anything remarkable about your CD drives' setup? Multiple drives or something? |
|
Thanks for the fix. Next time there's a downloadable Windows version (alpha
is fine for me) I'll give it a try. (I see auto builds for Linux, but don't
recognize one for Windows, and I'm not currently set up to build for
Windows.) (I know, the below is WAY more than you asked for, but I hope it
helps with other issues.)
It's not media arrival notification: putting the media in the drive and
closing it is sufficient for it to populate the job list (and ejecting via
the CD drive's eject button is sufficient to clear the job list). It simply
doesn't start ripping it. The CD drive is HL-DT-ST DVDRAM GH22NS90. Just a
single CD drive using a vanilla HW setup. No visible variation between 32
and 64 bit versions that I've noticed.
I tried a (random) music CD with data base search enabled (one for which
there's data on the web), and it went right to work ripping the CD. With
data base search AND CDDB cache off (the latter is important!) it did not
auto start. I suspect the top-level bug is that it doesn't autostart if
there's no metadata/title information at all. Also see more on music CDs
below. (Having CDDB cache enabled masks the issue, 'cause it does find
titles!)
I'm actually dealing with audio books, which if you haven't done so, are
rather "nonstandard" in some ways, and that *may* be a clue. (Maybe "too
boring" is closer to the description.)
In the current case I've tried it with a couple of different audio books.
(Just disk 1 in both cases.) Both behave in the same way w.r.t. starting
ripping - populate the job list but do not start. (The other disks in the
book don't autostart either.)
The first one ("W" for short) shows "unknown artist" and "unknown title"
for all 18 tracks. There appears to be no attempt at any sort of metadata,
not even titles. (That's for disk 1 of 9; see below.)
The second ("S") is even weirder: I've attached two screen shots; it
started out the first way (with pseudo-titles for just a few entries), then
as I tweaked the options,
it started behaving the second way, where the titles are good until track
10, then just go away.. (This has 13 tracks total.) (Disk 1 of 6).
In general audio books don't have titles or metadata, although I've run
into a few that do, like "S" (sort-of) does. Those that do have titles
frequently vary between disks, usually starting "strong" and then dribbling
off into nothing on subsequent disks.. Same for embedded metadata. Same
for online metadata if it ever happens. (That's not much of a surprise -
it's a different audience.)
A perf issue: When "read ISRC" is enabled, "S" also takes 8-10 seconds for
the first track to appear in the jobs list and about 4 seconds each for
the other items to appear. I hear the drive seek as each item in the job
list is displayed. No ISRC is displayed in the Tags tab. (For this I have
the database stuff all turned off, so there's no web turnaround time to
find nothing.)
For "read ISRC", the "W" populates at a "normal" (to me) speed once it
starts (although it is audibly doing a lot of rapid long seeks). There is
absolutely NOTHING in the Tags tab except the obvious defaults ("unknown
artist", "device:...", and the length, track, and size.) (No database here,
either.)
Something else that I noticed: for a music CD, using the database, ISRC off
(if it matters?), it went right to ripping the CD. I then clicked the
fre:ac eject button while it was doing that. I successfully ejected the
media. I then tried to close fre:ac (X button), and it popped up a message
about "A conversion process is still active" and then there's a yes/no as
to whether to quit. Clicking either closes the popup, but in neither case
does fre:ac close. In fact I couldn't find any way to get it to terminate
(short of the process manager). Reinserting the CD didn't help with that.
With the CD drive open (nothing to read) the process manager is still
showing fre:ac using around 25% of the CPU (one core of 4 solidly in use).
Inserting an audiobooik CD (no database info!) populates the job list, but
the Encoding File field still shows the file it was encoding at the time I
ejected the disk (that should either be blank or some variation on "unknown
artist".)
Another (related) bug: forcibly stopping the population of the jobs list
pops up an errors window, which is OK (I guess), but the window can't be
closed (in any way) and clicking on the individual names it displays does
nothing. The only way out is to close the top window (twice), which Windows
treats as an error to report. (Maybe you've seen some of those from me
(today) if you're getting reporting from MS?) ("Forcibly stopping" is
pressing either the fre:ac or HW eject button - and that's a "not always"
bug - sometimes it succeeds and doesn't report the errors... I suspect
timing on the button press.) Repro: if you have a disk that's slow to read
ISRC (like "S") then you have plenty of time to press the eject button
while it's trying to read. (I don't think I would have seen this except
that I was tired of waiting for the slow population of the jobs list.)
While I've got your attention, a plea from the audiobooks crowd (of 1?).
The organization of audiobooks on the web (e.g. Librivox in particular) is
OK. So is what you get from Overdrive. Ripping to that format from physical
CDs is a pain because the concept of multi-disk album isn't frequent (or
particularly necessary) for music (that, or there's plenty of metadata
built-in or from the web). For audio books from CD (with no useful
metadata), the ideal organization (from my POV) is a folder/directory
containing a folder for each physical CD. The per-CD folders are named from
the disk number in the book, and the tracks are numbered in order of the
physical tracks: that is, something like the below. (Since both the number
of disks and tracks can exceed 10, 2 (or even 3) digit numbers are needed
so they sort correctly!) (In general, book players handle nested
directories in path name order to any depth, although I'm sure there's a
lot of variation.)
Book
Disk 01
Track 01
Track 02
...
Disk 02
Track 01
...
...
Any metadata should NOT be used (alone) as a file name unless you can be
sure that the names are in order. (Audiobook publishers pretty clearly
(from the bad examples I've seen) think that the physical disk defines the
order completely (and thus are sloppy about titles/metadata) - and they're
mostly right, until it comes to ripping.)
It wasn't practical to use fre:ac until you added the <currentdate> and
<currenttime> feature. Now that that's there, I can rip the book mindlessly
without it merging the all the "unknown artists" into one combined album
(likely with conflicts of track number and messed-up order). Adding an
(easily reset) sequential disk number would be nicer, but I can do a little
scripting to rename the date/time disk names after the book is done. I
don't want or need a track number counter that spans disks, but I can
imagine others wanting it. It might be useful to be able to add the ISRC,
or some similar per-disk identifier (if there is one) to the file/path
names, but since many audiobooks don't have that information, I personally
don't care much.
(Earlier strange track titles: note the damaged one.)
[image: image.png]
(Later: track 10 is just weird.)
[image: image.png]
Just so you know, the audiobooks I mention above are library books that I'm
transferring to my (nearly blind) mother-in-law's audiobook player. I'll
have to return them fairly soon if you need to know more about them.
However, it's a good bet that you could pick up any random audiobook and
get most of those misbehaviors (library or thrift store are good sources
:-) ).
Donn
…On Sat, Aug 17, 2019 at 8:45 AM Robert Kausch ***@***.***> wrote:
Thank you for reporting this!
The second issue (automatization options not being available after
creating a new configuration) is fixed now with the 7e33167
<7e33167> commit.
As for the first issue, there have been some issues with this feature on
Windows in the past (not only with the 1.1 development versions, but also
with 1.0.x). In some cases, Windows just does not seem to be sending the
media arrival message to all applications. Though it's strange that it
works for you with fre:ac 1.0.32.
If you have been using the fre:ac 1.1 64 bit version, could you try if the
32 bit version behaves better?
Also, is there anything remarkable about your CD drives' setup? Multiple
drives or something?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AKS2YT7DVMZVAXBGBQE7PGTQFAMKPA5CNFSM4ILRB4C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QOBVQ#issuecomment-522248406>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKS2YT73FN6CFP5SZD2TF4TQFAMKPANCNFSM4ILRB4CQ>
.
|
|
I just tried the very recent Beta. With the correct setup it works fine for me except for the original bug mentioned here: it doesn't autostart the rip. It does get the new-disk notification (it populates the joblist without help), but it doesn't actually start the rip until "Start encoding" is clicked. I didn't repeat the tests, but last time I discovered that this was because there was no metadata whatsoever available (nothing on the CD, and web search disabled because I know there's nothing on the web either). It did, then, autostart if the CD had metadata. Once it starts, it's great, and quite fast enough. I have an adequate solution to the disk number problem (the time/date is enough if I read the disks in order). |
|
Thank you for trying the beta and also for your longer comment from August! Unfortunately, I didn't have time to write a detailed answer yet as I was quite busy preparing the beta. You are right. Ripping does not start automatically when there is no metadata available. This actually was a feature request by another user and implemented earlier this year. The reasoning is that without metadata, rips from different discs would land in the same folder and/or overwrite each other (as you already experienced as well). Though this cannot happen when the Regarding your comments from your August post (again, sorry for not answering this earlier): Reading the ISRC for each track can cause some delay and/or audible seeking when adding the tracks to the joblist. The data that possibly contains the ISRC values is read in any case, even if the disc does not have any ISRC values. I think audio books generally will not have ISRCs, as these are issued only for music tracks as far as I know. So you might just want to disable reading ISRCs if you are dealing mostly with audio books. I can confirm the bug where the ripping process is not stopped when ejecting the disc and fre:ac cannot be quit then. I'll try to fix this for the next beta. Thank you for pointing this out! Likewise for pressing the eject button while adding disc contents to the joblist. Regarding a sequential disc number counter, that's already on my list of possible future features. So it's likely this will come with fre:ac 1.1.x or maybe 1.2. This will also include options to re-number tracks from an arbitrary starting point or use a disc-spanning track counter. |
|
Thanks! I'll look forward to all the changes. With respect to auto-start in the absence of metadata: for most (non-audiobook) users, auto starting the rip in the absence of metadata is probably the right thing (particularly if they didn't know in advance that the CD was odd!). But then there's the audiobook crowd (and some home-brew CDs, probably). I'd personally be just as happy with another checkbox of the form "Allow autostart without metadata", rather than trying to infer the user's intent from the path name. That alternative also announces your intent clearly, so it won't be perceived of as a bug or obscure behavior - the user would perceive it as a "a-ha" sort of feature, and it would also implicitly guide the user to think about why that's an issue and what would work best for them. Some sort of message of the form "autostart not done because metadata missing" would also be good guidance and probably clear up a lot of user mysteries. (Some sort of implied message, such as red in the joblist, or making the message I suggested above turn red if it applies, would be fine too.) Whatever works in the balance between needs and your available time is fine. |
|
Beta 2 is now available and should auto start ripping even when no metadata is available, as long as It also should improve behavior when ejecting a disc while ripping or while adding tracks to the joblist. |
|
(Finally got to testing.) Works as I had hoped. Thanks very much! |
|
Great! Thank you for reporting back! Closing this issue then. |
Describe the bug
Two (possibly) related issues:
To Reproduce
Steps to reproduce the behavior:
Version 20190423.
Then Ripper->Settings->Automation "Read CD Contents on Insert" and "Start Ripping Automatically" are greyed out.
Restart application and they are available.
Expected behavior
Options should be available just after creating a new configuration (no restart should be needed).
Auto Start Ripping should actually do that.
Screenshots
If applicable, add screenshots to help explain your problem.
System (please complete the following information)
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: