mp3 Compare

[penguin22]

Hello,

Currently I've had to default to BC2 when I want to do more than a size based compare of mp3 files. The rule works, but is extremely slow as I believe it also compares the audio by some method as well as the tags. Is it possible to have a rule or set of mp3 rules in BC3 by default (as part of the default rules that the program will ship with) that will compare by tags and or tags and audio. A tag only compare would cut down on the 3+ hour compare time that it currently takes and as most programs update tags without modifying size or date stamp, you can see the need.

[Aaron]

MP3 Rule not Present in current build

We have not implemented BC2 MP3 functionality into BC3 yet, so when you do a Rule compare, you are Text Comparing your MP3 files. This would explain the extreme length.

Please continue to use BC2 for MP3 tag comparison, or BC3 for CRC/Binary Content Comparisons.

[penguin22]

I am aware that the mp3 support is not in BC3, the slowness exists in BC2 as well as the rule compares the tags as well as the audio. When you want to compare 26,000 mp3's it takes many hours to complete and if you know that both sides are the same mp3's with only tag changes, it is tedious and cumbersome.

An improvement for BC3 (unless this belongs as a post for the BC2 rule creator) would be to have either two rules, one for mp3's without audio compare and the other with mp3's also comparing audio. I hope that you can see the benefit to this. Even a checkbox saying, "Compare Audio" in the settings for mp3 compare would more than suffice.

One of the many functions that I use BC for is mp3 compares of close to 3,000 mp3 CD's and I update tags frequently. Most of the time, a date/size comparison misses these changes and the only way to detect them is to use BC2 with the rule, start the compare and walk away for (measured at 5 as of today) hours.

Thanks for all the great work to date by the way. I love BC and would never want to be without it :-D

[Unregistered]

Perhaps a better way would be to treat mp3 files as an archive format, and when it is opened, present two files, one for the audio data, and another for the tags. You could then exclude the audio from the comparison by using filters to exclude the filename.

Comparing audio is going to be a tricky problem anyway, and idealy we want another viewer, in the same way that the picture viewer is different from the text viewer. That viewer would present audio as waveforms, similar to how they look in other audio editors when zoomed out, and could then compare audio in different file formats (wav, flac, aac etc) and bitrates, and use a psychoacoustic model to determine which differences are inaudible and therefore unimportant.

[Michael Bulgrien]

idealy we want another viewer, in the same way that the picture viewer is different from the text viewer. That viewer would present audio as waveforms, similar to how they look in other audio editors when zoomed out, and could then compare audio in different file formats (wav, flac, aac etc) and bitrates, and use a psychoacoustic model to determine which differences are inaudible and therefore unimportant.

Great ideas! Can anyone say, "BC4 - Audio comparison is getting a whole lot easier"? Seriously, if well implemented, I would use audio comparison features like this more than I'll ever use Picture Compare features. In addition, a thumnail of differences could be utilized to help users move to areas of an audio track that contain significant differences.

[Marjolein Katsma]

Great ideas! Can anyone say, "BC4 - Audio comparison is getting a whole lot easier"? Seriously, if well implemented, I would use audio comparison features like this more than I'll ever use Picture Compare features.

I can't say I would use it a lot more than picture compare, but I'd definitely have a use for such an audio comparison. I quite often have several MP3s of the same piece of music recorded from a radio station and it's tricky to figure out which is the "cleanest" recording; a wave-form comparison would easily show which one had a bit of a previous or following piece pre/appended, for instance. Now, I basically have to listen to start and end of each to find the "best" one - a visual comparison would save a lot of time. Just an example, and it's for entertainment, nor development - but I like to listen to music while I work.

[penguin22]

Good discussion... for some reason I stopped receiving notifications on this topic or I would have contributed more. I primarily use the mp3 compare for tags alone so I have to agree that splitting the feature into two parts is a great idea! The Quality concern is also great, however, as I have previously ripped CD's with different LAME settings using CDex and if I could compare to clean rips to determine the worth of re-ripping using VBR and a newer version of LAME, it would be another benefit.

Are there talks of rules being updated as part of the BC3 development or is this up to non BC3 coders? I just want to make sure all of these great points and discussions are heard by the people with the knowhow. I'm no coding genius, but someone see this and be able to run with it :-)

[chrestomanci]

I was the unregistered user who put in the suggestion about comparing audio.

Looking back, I think that it is a nice blue sky idea, but the chances of it happening are slim. Audio would have to be fuzzy compared using some sort of phyco-acoustic model, because unless the left and right files are lossless recordings with the same settings from the same source, then any sort of binary compare will find differences where there are none.

To do a phyco-acoustic compare, the coders at Scooter software would need to rip the guts from an encoder like Lame, and substantively modify it to add hooks that will give them the frequency spectrum at each point in time, that "ripping the guts" would require a license from the source code owners which would cost money, not to mention all the coding time for a feature that is of fringe interest to most people.

Even if the money where negotiated, there is still the amount of computer time required to process each file, as it would take a similar amount of work to study each audio file as to encode it to mp3, so even on a fast computer, comparing two directories of 20 mp3 files (2 different rips of the same album for example) would take at least 5 minutes of 100% CPU. Seeing as we are used to beyond compare being very speedy, a lot of people would complain about that sort of delay to process a relatively small number of files.

[penguin22]

Well that's no fun on the audio side of things, though I do agree with your comments... even though LAME is open source, the effort would be intense. The only thought there would be a spectral analysis of the audio rather than a binary or similar compare. In other words, take a sample of the audio represented with a graph and compare with a tolerance for normalization and display the differences. The other part would be a time slider to adjust the timing to better align the sides if possible. Where this would be interesting is if you want to compare a live track with studio and see the differences, you could align parts of the song that are similar, knowing that most of the timing would likely be off. All of this being said, I really doubt that this is a BC feature/need so much as a basic compare. For all I know, this could already be in software like SoundForge, etc.

The second part, and what I still feel is possible is the tag part. It is mostly a text compare and if the performance was optimized, it could be extremely useful to more users than the current scope of BC users. Using the example of having ripped mp3 CD's at a 160 bitrate. If a desire to replace them with VBR or 192, it would be awesome to have the 160 on the left and the higher bitrate on the right. I know my left tags are accurate and they have high quality album art. All you would need to do is copy the tag info to the right and your tags are all in order. Second to that, you could open and inspect them tag at a time. The most important part is that if you only care about the tags, the slow audio compare won't be necessary.

[Schlitz]

MP3 bitrate

Hello,
I would be very happy if it is possible to have the bitrate displayed in the comparison window.

[chrroe]

And the over-all playtime (mm:ss) of a MP3 file would be interesting, too.