On Thu, Jul 03, 2003 at 11:44:11AM +0200, [EMAIL PROTECTED] wrote: > But since you're asking, I must say I can't see why you want LAME to do > this. As I see it, your program should take care of all the error-handling. > Personally I would always prefer error messages to having a resource > silently doing something else, because then I can take action to deal with > that error instead of losing control with what's really happening. I mean, > for instance, you wouldn't code functions to silently do something instead > of reporting back errors when they occur? And I can't see why it should be > very difficult to implement error handling in your frontend. Actually, > having the errors reported give you many possibilities, like letting users > define rules of what to do when a specific genre fails the standard, like > "Underground Swede Pop" -> "Swede Pop" etc. I see error reporting as a > necessity, and I for one oppose your patch, no offense :)
None taken. Lets try to sum this up without being too verbose. Reasons -I- (as a YaRET front end) want a silent ignore path: 1) I've already asked the user to confirm his/her choice. 2) It's only a tag, not an irreversible encoding problem. (And not like I'm mangling an important tag either, like Artist or Album). 3) YaRET is a batch system, so user interface really isn't part of it's vocabulary (e.g. tar, rm, patch, all are similar, you can turn -on- confirmation, but by default they assume what you said is what you meant (except tar, who cowardly refuses to create empty archives :) )). 4) I don't know about the genre problem until it's too late (that is the system is half way through the process). So any solution that prompts the user about the problem is not ideal (see 2). 5) I simply do not see the value of keeping a genre list (or having a configurable source (i.e. execing lame --list-genres)) in YaRET. That's a lot of trouble, and again the user interface for confirmation will still be less than ideal (even though it could be located at the beginning because of having a list). 6) (As per your suggestion) I definitely don't need the user's values to be transformed from the user's values. (I mean, if you mean Swede Pop, why bother typing Underground Swede Pop). Of course your suggestion has merit if you want to encode to multiple formats, and the others do not (and they don't) have the restriction on genre. 7) At the least, my problem is entirely specific to id3 and lame's interface to it. I do not want code in my layer (YaRET) to mimic the behavior I get from the other encoders; it would be very nice to have the behavior implemented the next level lower (in lame). Ok that's it. Now as for the argument just concerning reporting error messages: I'm pro. I think you should. But as I state from above, it's my choice to ignore the error in -this- situation. You can't always ignore the situation in favor of an ideal. Anyway, (let's assume that your using lame manually) why is it -bad- to provide an option that just says "I the user, don't care". It's much like the quiet option. If the user doesn't want it, don't do it; even if the user could do it himself (e.g. 2>&1 >/dev/null, instead of implementing a --quiet). Anyway, I can see that it may not be appreciated why I (again, as a YaRET front end) would want to ignore that error. So I appreciate Alexander in allowing me to write a patch (on faith, or understanding). But I do agree that most times you do not want to ignore errors. Ignoring errors, in general, -is- bad design, especially for user interfaces. (Luckily YaRET considers itself exempt from a user interface; I know, I asked). Trudging through, Adam _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
