[mb-users] Replacing Windows-Incompatible Characters

[Adam Golding]

Philipp,

  I beleive it was you I was talking to in the irc channel.  I was thinking
more about the case of / and \ characters.  I think this is why the other
solution I mentioned is more ideal, that of customizing the stage where _ is
inserted in the first place.  Then, rather than using $replace to decide how
non-windows characters other than / and \ are treated, it would be chosen
elsewhere, in a separate options pane of picard, which contains a list of
illegal windows characters, and values that they will be replaced by.
Obviously the program would have to not accept illegal replace values.  The
default could be left at underscore for all values to avoid messing up older
scripts, but the user could still customize this, even in the case of / and
\.  I believe I've seen this in other mp3 renaming programs, too.  Everyone
let me know what you think :-)

2008/6/23 Frederic Da Vitoria <davitofrg at gmail.com>:

> On Mon, Jun 23, 2008 at 12:24 AM, Philipp Wolfer <phw at rubyforge.org>
> wrote:
>
>> On Sun, Jun 22, 2008 at 11:45 PM, Frederic Da Vitoria <
>> davitofrg at gmail.com> wrote:
>>
>>>
>>> I disagree.
>>
>>
>> I just explained how it currently works, no reason to disagree.
>>
>
> Ah, I misunderstood, sorry.
>
>
>
>  Users should be able to decide. Picard's current behavior is correct only
>>> as a default behavior, not more. What Adam is trying to do makes much more
>>> sense to me than Picard's default behavior. And anyhow, showing what will be
>>> done then doing something else is definitely not user-friendly.
>>
>>
>> Picard 0.10 will make the Tagger script evaluation before the replacement
>> of invalid characters. That way a substitution like Adam is trying to do
>> will work, as long as you use a valid character as a replacement. And the
>> preview will match the final output.
>>
>> There is one limitation however: Slashes and backslashes (the delimiters
>> between directory names) will still be replaced by underscores, no matter
>> what replacement you define. This is not easily solvable.
>>
>
>
>>
>> However, in the end the file names are always subject to technical
>> limitations, which are different on various platforms. So not every
>> desirable naming can be achieved. That's why I suggest to rely more on file
>> tags than on file names for the details. Of course the filenames should be
>> customizable and as good as possible, after all that's one of Picards most
>> important use cases.
>>
>
> Of course.
>
> --
> Frederic Da Vitoria
> _______________________________________________
> MusicBrainz-users mailing list
> MusicBrainz-users at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-users/attachments/20080623/ec5a52b3/attachment.htm