alignment override

[150d]

Hi,

I've been reading about how to use "override align" in folder compare, but I just don't get it.

My problem: I want to align this file

08 - Wild Child.mp3

with this one:

08-enya-wild_child.mp3

I don't even understand the concept. I'm (somewhat) aware of regular expressions, but I don't understand which part of the filename I'm supposed to describe on which side.

Could anyone help me out here?

Regards

[Aaron]

Hello,

The file mask would need to match for the part of the name that is equal.

I would want to get a few more examples, but if you have several files with whitespace in one, but _ in another this will be a difficult alignment to define, since the _ in the destination each have to be explicitly part of the string:

(\d\d) - (\w+) (\w+)\.mp3
to
$1-enya-$2_$3.mp3

A simpler example of how this would be used would be if one file name had a track number, and the other did not: 08-Wild Child.mp3 = Wild Child.mp3 with:
\d\d-($1)\.mp3
to
$1.mp3

[150d]

Hi,

ok, you already helped me much in understanding the process (on a still very basic level - sorry :-) ):

When I want to align the two files

common_alpha.ext
common_bravo.ext

I need to specify a mask of "common_*.ext" on the left side, and I need to make substitutions to be able to reference the parts on the right hand side. In this case, how about this:

LHS: $1_[a-z]*\.ext
RHS: $1_[a-z]*\.ext

In my understanding: $1 will be an identical string on both sides, next will be "_" on both sides, then both sides will match any a-z substring of any length (might be different beween LHS/RHS), then both will match ".ext".

Is this correct?

Do I need the backslash before ".", and do I need brackets around "$1" (as you used in your examples?)


To get back to the example from my first message:

If we assume that every file has the track number as part of the file name, would that help?

So I can reduce the problem to the mask

[numeric]something

or as regex:

LHS: [0-9]*[a-z]*\.mp3
RHS: $1[a-z]*\.mp3

I'm assuming the $1 stands for "element of expression", which can be either pure text or a single definition (here: [0-9]* ). Is that true?

I would want to get a few more examples, but if you have several files with whitespace in one, but _ in another this will be a difficult alignment to define, since the _ in the destination each have to be explicitly part of the string:

Can't I just match [a-z_]* instead of [a-z]* ?

(\d\d) - (\w+) (\w+)\.mp3
to
$1-enya-$2_$3.mp3

That would work for names with two words in them, as in

01-enya-one-two.mp3
but not for
01-enya-one-two-three.mp3

Right? (Just wanting to make sure I'm following.)

A simpler example of how this would be used would be if one file name had a track number, and the other did not: 08-Wild Child.mp3 = Wild Child.mp3 with:
\d\d-($1)\.mp3
to
$1.mp3

Wow. That one I got without even asking back. :-)

Thanks a lot for your explanations!


Regards

[150d]

I still can't get it to work. The example you suggested is fine, but it is limited to a specific number of words seperated by "_" or spaces and I can't get it to be generic.

I tried the following:

LHS: (\d\d) - (\w|\s)*\.mp3
RHS: $1-enya-(\w|_)*\.mp3

Decoded, LHS: Match two digits, match the sequence space-dash-space, match any number of alphanumerics or spaces, match the sequence ".mp3".

RHS: Match the same two digits as in LHS, match the sequence "-enya-", match any number of alphanumerics or "_", match sequence ".mp3".

Yet, it aligns nothing.

Can you find the mistake I made?


Regards

[150d]

... or even simpler:

LHS: (\d\d) - (.*)\.mp3
RHS: $1-enya-(.*)\.mp3

Why the heck doesn't this work?

Regards

[Aaron]

The issue might be that in your above example (alpha and bravo), alpha can be matched using a RegEx mask, but the destination side cannot use similar masks. "bravo" must be explicitly set and the right side cannot use .* or any other RegEx other than the references ($1, $2, etc). You can click the dropdown arrow to see the list of supported commands for each of the "left" and "right".

Unfortunately, while you can match the original song name with (.*), you cannot reference it on the right side with $1 because it is not an exact match. The right side name is using _ instead of " " whitespace. This would require RegEx that matches on each word, not including the whitespace, and then referencing them individually. This won't work well if the song names have different amounts of whitespace (which they likely do?)

(.*)\s(.*)
=
$1_$2

[150d]

I see. Is there a technical reason for this (RHS only processing limited regex) or was it purely a design choice?

For the time being, I can probably compensate using a two step process:

1.) Rename the RHS files: replace "_" with " " (I'm using an excellent program called "Renamer" which is quite capable in such cases)

2.) Use BC to compare the folders: Since the song title is now a complete match it should work out all right.

The drawback is that this only works if the song title actually is identical between the two sides - which happens to be the case here, but usually won't be. I'm still looking for a way to auto-align

"03-firstfile.ext"
to
"03-secondfile.ext"

purely because of the "03-" matching part.

Is the current state of this part of BC considered to be "final" or are further improvements planned?


Regards

[Aaron]

Improving this area is on our Customer Wishlist, but isn't currently scheduled development. It would be hard to predict when these enhancements would make it into Beyond Compare.

Are the song files themselves identical except for the name? Aligning based on content other than the name is also something on our Wishlist.

[150d]

Are the song files themselves identical except for the name? Aligning based on content other than the name is also something on our Wishlist.

That's exactly what I want to find out: Let's say I have two versions of an album, and I want to find out if they're identical. On a glance, based on the number of files I have the suspicion that they are, but the naming structure is different. Currently, for 16 tracks I have to do "align with" sixteen times to check this.

Then, if they're not binary identical: Maybe it's just the MP3 tags, not the data content? To find that out, I can use "compare with", which will tell me that yes, the audio data is the same, in spite of differing file sizes - but again I have to do that sixteen times.

Improving this area is on our Customer Wishlist, but isn't currently scheduled development. It would be hard to predict when these enhancements would make it into Beyond Compare.

Any chance to push this up a little? ;-)

This is a daily use case for me. Just now, I've got more of the same:

B02-01-12 - Live and Let Die.mp3
B02-02-12 - Live and Let Die.mp3 [...]
vs.
001 - Live And Let Die.mp3
002 - Live And Let Die.mp3 [...]

I have no idea how to coin this in BC, and manually it's a pain.

Regards

[Aaron]

Hello,

Sorry for the difficulty. BC3 really relies on either the file names being equal, or being able to define an Alignment Override to get a pair of files to match. I'll add your various examples to our test cases, and it is something we would like to tackle, but it is not likely we would be able to deliver something quickly. I would maybe suggest searching for a dedicated "Duplicate File Finder" utility, which might help scan a directory and find identical (binary) files. I know of a few, such as:
http://www.howtogeek.com/howto/the-g...ly-identifies/
But I am not familiar with one that scans MP3 tags. Please note that this is not a Scooter Software product and is not supported by Scooter Software.