Sometimes you have a folder with a ripped CD inside it, but
the songs are labelled Track 1, Track 2, etc. There's no CDDB info.

This might be because you ripped it using and old version of abcde,
or some other ripper, or the CD was not in the FreeDB database when
you ripped it (and you were too lazy to type it in yourself) but
since then someone else has entered it for you.

So the new feature would be to use the number of tracks and the lengths
to figure out the FreeDB entry (if there is one), then allow various
actions to apply that info:

rename - renames the folder and files using the new FreeDB info
playlist - generate a playlist (useful if you didn't do it first time round)

This feature would also be useful if you want to change the naming system
for your music files. You could rig up a new scheme in your .abcde.conf
then apply it to previously ripped CDs.

Thanks for abcde!

Cheers,
m.

wontfix and no response from submitter so closing

reopen 129624 !

thanks

Debian Developer C. Tuckley marked it 'wontfix' and closed it a week
later. Reopening because:

	1) A closed 'wontfix' implies a fix.
	2) Other users (me, for one) crave this feature.
	3) Tuckley thinks the 2002 submitter not replying is notable.
	   Irrelevant -- as the Python song goes: "Beethoven's gone,
	   but his music lives on..."

HTH...

Sorry maintainers, if that last message was too clipped.  After sending
it, I looked through the changelog, and noticed  that Tuckley's doing a
lot of work on 'abcde'.  Of course I'd just figured CT was some random
fella, (I still think this bug should stay open tho').

But since I'm probably not the first person to make that sort of
mistake, maybe there's another 'wishlist' in this.  Maintainers change
too, but submitters and BTS browsers may not know about who has what
job.  Maybe a maintainer's taglines should clearly explain the work
they do for the current package.  Examples:

	# the current maintainer
	John Smith, current Debian Maintainer of 'foobar'

	# former maintainer
	John Smith, former Debian Maintainer of 'foobar'
	John Smith, Debian Maintainer Emeritus of 'foobar'

	# second banana
	John Smith, Debian Developer and code contributor to 'foobar'

NB: the tagline shouldn't say every package whosie does, just the
relevant one(s) relative to the package being discussed.

I'd think of it like a distinctive insignia on a uniform (as with
military brass).


	- Sincerely,
	  A. Costa, independent BTS grouser and user of 'abcde'

Maybe if you looked at the QA page for the package:

http://packages.qa.debian.org/a/abcde.html

you would have noticed that I'm actually one of the maintainers of abcde.

I didn't just mark this bug as won't fix and close it, I talked with Jesus
about it first.

Wontfix doesn't just mean we won't fix the bug. It means that we believe the
bug is not actually a bug at all - not even a wishlist one.

In this case we believe that adding this functionality would violate the
Linux principle of "do one thing and do it well".

The bug has been around since 2002, in that time no one else has asked for
the feature. We are trying to clean up abcde and having bugs like this one
hanging around just makes seeing the real work more difficult.

If you want the feature then submit a patch, or preferably in this case,
write a companion utility which does what you want.

Colin Tuckley writes:

Are you and J. sure?  Package description says:

	...Grabs an entire CD and converts each track to the specified
	formats and then comments or ID3-tags each file, with one command.

I take the "one thing" as all those steps, collectively.  So that
failing one step, owing to variable circumstances, 'abcde' currently
allows one to do many things over.  For example, if the rip fails
partway, (say the DAE on a CD drive is weak) 'abcde' still keeps a temp
directory with CDDB data, and allows one to continue later, (on a CD
drive with better DAE), without starting from scratch (no pun
intended).  So there's already "do over" functionality. I don't
understand why a proposed CDDB/ID3 tagging "do over" should
conceptually be any different than an extant ripping "do over".

Quoting "A. Costa" <agcosta@gis.net>:

The whole point of abcde is to do things with a CD!

This bug is about trying to fix something without the CD being
available, as such it isn't part of what abcde is designed for.

The bug isn't talking about a "do over" it's talking about fixing
ripped files when the CD isn't available.

The philosophy of abcde in the situation where the tagging info is
missing or incorrect is to re-rip the CD. If the CD isn't available
then some other tool is needed.

We might have been arguing about two different things.

Making a backwardly compatible completely automatic retagger for all
older 'abcde' versions would be difficult, (guessing a discid from a
tagless encoded file, can it even be done?), and sounds like a job for
a sophisticated forensics util.

I had in mind stuff like...

"Prepared retag psuedo-algorithm": during first run, suppose
CDDB server has nothing.  Save the cd-discid somewhere in a tag field,
such as 'comment' or 'encoded by', e.g. "abcde v2.7 from discid
12345678". During a retag, check the saved discid and proceed as before.

"no guessing backwardly compatible kludge": let the user enter the
discid, after they find out what it was, or insert the original CD
solely for the purpose of getting a discid to look up.  etc.

And a responding comment...

'man abcde' implies otherwise:

       -C [discid]
		Allows  you  to  resume a session for discid when you no longer have
		the CD available (abcde will automatically resume if you still have the
		CD in the drive). You must have already finished  at  least  the
		"read" action during the previous session.

The phrase "when you no longer have the CD available" is plain
enough.

Anyway using an available CD to get a discid sounds fine.  But it's not
efficient to require (re)expending computer resources ripping,
encoding, and all that.  At the end the user still winds up with a do
over of the tagging.  Doing every step twice, versus re-doing one
missing step -- a big win, especially when the missing step is quick
and the other steps are slow.

Quoting "A. Costa" <agcosta@gis.net>:

Submit a patch.

The -C option is to allow the encoding to be resumed if something
fails after the CD has been ripped to the intermediate .wav files
(perhaps if -l was specified). It doesn't have anything to do with the
tagging as such.

reopen  129624 !

thanks

Some kind of spambot accidentally or recklessly closed this bug.