Announcement

Collapse
No announcement yet.

Picture and MP3 compare

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Picture and MP3 compare

    I have been a Beyond Compare user since 1998 (v1.6 or something like that). A couple of days ago I was discussing a directory comparison situation with a fellow on a linuxquestions.org forum. As he did not have a Windows machine available I wanted to see if BC would work under Wine. Rather than dig through my archives and find my install files for BC2 I decided to just download a copy from the web site. Imagine my delight when I found that BC had been ported to Linux. So I purchased my Pro license and am exploring some of the features in BC3. Thus my question...

    I have used BC to compare files, folders even entire hard drives. I have made use of the hex compare/viewer (that is why I quit using MS Office many years ago - an interesting story). I have compared and merged source code. But now in BC3... Can someone please provide me with a little insight on the use of the picture and mp3 comparison tools?

    I have used a binary compare to see if a picture or mp3 file was corrupted from the original copy. Either it was or it was not. Where or how much corruption was present did not seem important. I had a good copy or I didn't.

    I am unable to wrap my head around what I would use the BC3 picture or mp3 comparison tools to accomplish.

    TIA,

    Ken

  • #2
    Hi Ken,

    The picture and MP3 player are useful when you're making changes to the files, just like the text compare is. For example, you could compare images to see if a logo was changed, or if color was shifted. It can also compare images of different types, so you can see if a BMP->JPG conversion worked correctly. I know one user is using it to check for bugs in graphics drivers (dumps of the framebuffer).

    The MP3 viewer is generally more useful when you're trying to reconcile differences. It compares the tags and music data separately, so if you've updated the tags on one side and not the other it can show that while still showing the music as matching.
    Zoë P Scooter Software

    Comment


    • #3
      Hi Ken,

      The MP3 compare can also help find music files that have the same audio content, but different tag data. Uisng the HEX compare on two similar MP3 files allows you to see if the content is the same, but leading and trailing silence have been removed on one of them. Hex Compare also lets you see if the MP3 volume has been changed on one. Since the MP3 volume is simply an amplification factor in the MP3 Frame Header, the audio data isn't affected, so two audio files with the same audio data but different amplification factors are "the same". Amplification can be adjusted with "MP3TRIM" or other audio processing files. MP3TRIM Pro has the ability to "normalize" the volume of all the audio files in a directory.

      Another Ken

      Comment


      • #4
        Thanks folks for your input. I guess I need to play around with some image and mp3 files. So far I tried comparing two mp3 files, ripped from the same CD. One with Sound Juicer on Linux and the other with CDEx on a Windows XP virtual machine running on the Linux host. The settings for bit rate etc. in the ripping programs were the same as best I could tell. When I compared the files I found that the header data was a little different. Sound Juicer filled in more information. I also see that the sound data is different in size by about 9 kb of 5.8 Mb.

        I do not find the "MP3 volume" listed. That would be handy as I have a couple of CDs which ripped to rather low volume and it would be nice to be able to boost the volume. Of course I will have to figure out which of my 380+ CDs are so effected.

        Thanks again,

        Ken

        Comment


        • #5
          And I solved another one...

          Years ago I ripped my Great White CD "Twice Shy" on a Windows machine. Since then I copied all of my mp3 files to my Linux box and from there I copy a few albums at a time to an SD card to play in my mp3 player. One day I decided to grab this particular album. When I opened the Great White subdirectory it was empty. I re-ripped the CD from my Win XP virtual machine on the Linux host and again got an empty subdirectory (at least from the Linux point of view). Seems that CDEx created the structure CDEX\Great White\...Twice Shy. The leading . of course made the subdirectory hidden in Linux.

          So just now I grabbed the CD and ripped it with Sound Juicer directly on the Linux box. I examined one of the mp3 files with BC3 and low and behold, the album name (read from the actual disk I believe) is "...Twice Shy". CDEx used the literal value of the album name in creating its directory structure.

          Ken

          p.s. I had posted a thank you reply with some discussion of what I had done so far with the mp3 compare - thus my statement "...another one" Not sure what happened to that post. I did not notice it was missing when I started typing this one. So again thanks Craig and RunnerBiker for your responses.
          Last edited by taylorkh; 18-Jul-2010, 01:56 PM.

          Comment


          • #6
            The "volume" is not viewable with BC3. The volume information is embedded within an MP3 Frame Header. Although you can not actually view the volume, you can adjust it with MP3TRIM (http://www.mptrim.com/).

            When you use different rippers, they will produce different mp3 files. Even though you may set the rip parameters the same, the rip engines will analyze the audio data differently and then the encoder part of the ripper will generate unique mp3 data.

            You have already seen that the header data can vary depending on the ripper. And "..." is not a good idea for the start of a file or folder name.

            For more information on the content of an MP3 file, check out http://www.id3.org/id3v2.3.0 or http://www.mp3-tech.org/programmer/frame_header.html

            Good Luck

            Comment


            • #7
              I see my second post has appeared. Not sure why it showed up late.

              Thanks for the tip on MP3TRIM. I will have a look at it. As to the name of the album - it has been sitting on my desk since I re-ripped it. And I finally took a closer look. The actual name is ". . . T W I C E S H Y" as shown on the cover and the CD it self! So the Windows based rippers created the directory structure based on what they were given.

              Ken

              Comment


              • #8
                Originally posted by Craig View Post
                Hi Ken,

                The picture and MP3 player are useful when you're making changes to the files, just like the text compare is. For example, you could compare images to see if a logo was changed, or if color was shifted. It can also compare images of different types, so you can see if a BMP->JPG conversion worked correctly. I know one user is using it to check for bugs in graphics drivers (dumps of the framebuffer).
                I've been down the aisle where comparing pictures using a straight binary comparison is an issue, due to various header comment fields being touched by camera software (on already uploaded pictures!). The picture rule works nicely to compare the contents while ignoring the comments. There is also an EXIF rule that lets you see what is happening to the header information.

                This is similar to the comments about the MPEG viewer already posted here, but it is nice to be clear how it helps with the pictures.

                /dps

                Comment

                Working...
                X