Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[markf2748]

To get another view of what is going on:
Do a binary side-by-side comparison of the contents of the two files.  For example, the program Beyond Compare can easily do this.  BC shows a line-by-line view using its intelligent alignment algorithms which are pretty effective at detecting gaps or large sections of differences.

The file compare allows you to see if file differences are restricted to the header section, the music section, or appear in both.

I sometimes find that two flac files for the same track are different, but the files are the same size!  In my cases, it is always due to a re-writing of the file header with some tags in different positions within the header, while the music sections are binary identical.  Header buffering keeps the file sizes the same.

So not exactly your problem, but you might learn something.  Since you say the audio CRC's are the same, it could be something in the headers like extra buffering, which you raised.  That would be immediately obvious in an intelligent side-by-side comparison.  On the other hand, if it is a bit rate effect, that might show up as differences in the music section.

[Awesome Donkey]

I originally thought the same thing too, that it could be a difference in FLAC compression, but with the changes being within 800kb I thought that might be too small of a change to account for a different compression level.

With the hashes being different, that means the files are different to each other. The question now becomes why... is it metadata? Embedded artwork? Or something else? More importantly does it happen again if you straight copy the file from the NAS to the other drive? If it only happens once maybe it's a fluke but if it happens again that's a brain scratcher.

Beyond Compare is excellent for doing binary analysis of multiple files. You can also open both files in a hex editor and do a comparison between them to see the differences.

[Von]

To get another view of what is going on:
Do a binary side-by-side comparison of the contents of the two files.  For example, the program Beyond Compare can easily do this.  BC shows a line-by-line view using its intelligent alignment algorithms which are pretty effective at detecting gaps or large sections of differences.

The file compare allows you to see if file differences are restricted to the header section, the music section, or appear in both.

Thanks for the tip, I will take a look at Beyond Compare. It would be interesting to see which parts of the files are different.

Do you have two copies of the same album/track on the source NAS which were ripped with different FLAC compression ratios, or contain different embedded images?

No, there is only one version of the song on my NAS.

With the hashes being different, that means the files are different to each other. The question now becomes why... is it metadata? Embedded artwork? Or something else? More importantly does it happen again if you straight copy the file from the NAS to the other drive? If it only happens once maybe it's a fluke but if it happens again that's a brain scratcher.

The file was copied twice. Once when the process was paused and then resumed later, and once to check what might have caused the difference in file size between the first copy and the original. I'm not sure what you mean by straight copy, but I guess it would be what I did the second time?

I have tried to recreate this by doing another copy process, pausing it for several hours, and then resuming. This issue did not occur then. We can call it a fluke – but I think it's an interesting one. 

[zybex]

You can use Metaflac to see the metadata content of both files. An embedded cover added when you played the file is the most likely answer.

[Von]

I am trying out Beyond Compare. It looks powerful, but I will have to get to know it better.

What I can see straight away, is that the difference between the two files is 84,263 more hexadecimals in the bigger file. If that makes sense? To be precise, maybe that should be 84,263.25 more hex values. There seems to be 674,106 pairs of zeros in the bigger file, which are not present in the smaller file.

I have yet to find out where in the file this is, but I guess this has to be padding?

If anyone can help me pinpoint where in the file this difference actually is, please let me know.

[markf2748]

I am trying out Beyond Compare. It looks powerful, but I will have to get to know it better.

I suggest trying BC 5 (beta).  BC 4 (release) also provides a Hex Compare but not a FLAC Media Compare.  There is definitely a learning curve.  It's worth studying the color codes (summarized in the View menu).

BC5 Folder Compare --> File Compare:

1) Put the two files you want to compare into different folders, being sure both have exactly the same filename.
2) Open a new Folder Compare Session either from the Home window or menu Session > New Session > Folder Compare.  Enter the two folders.
3) You will see the two files on the same line.  Hit the "Diffs" toolbar button to see just files which are different.
4) On the line with the files of interest, double click in the empty column centered between the left and right folder displays.  The empty column entry changes to "not equals" sign and BC opens a new tab based on a binary compare of just the two files.
5) BC 5 detects the media type, and the new tab defaults to a Media Compare view showing a nice side-by-side list of Metadata for the two files, followed by Audio Data.  No line numbers or byte addresses.
6) To get hex detail broken into binary "lines" with leading Byte Addresses, switch to:  Session > Compare Files Using > Hex Compare.  Be sure View > Byte Addresses is selected.
7) You can switch between viewing "All" and just "Diffs" in the binary file compare using toolbar buttons, same as for folder compare.

BC 4 works the same way, except the binary file compare defaults to Hex Compare.

Hex File Compare in two steps:

From BC's Home screen, click right chevron and select "Hex Compare", or use the menu Session > New Session > Hex Compare.
Enter the two full file paths to fill the left and right file comparison windows.

-----

A large block of zero-valued bytes is most likely padding.  The general ordering of FLAC files is header tags - embedded images - audio data.  For FLAC file structure details, see https://xiph.org/flac/format.html#scope

You can find locations in the binary file using Search > Find, entering either hex or text values.  For example, search for hex bytes "00 00 00 00" to find zero-valued blocks.  To find embedded images in a FLAC file, search for text "image".  If your file has five embedded images, then you should get five hits for "image".  Images are also listed in the Media Compare view.

BTW, BC 5 features a slick modern dark mode skin - black, grey, colored button icons, and user selectable text/highlight colors (Tools > Options > Appearance)!   


5/14/2024: Edited multiple times for clarity.

BC 4.4.7 | BC 5.0 Beta (build 29328) | Disclaimer:  I have no business association whatsoever with Scooter Software, Inc.  I'm just a delighted daily user of BC since 2005 and early contributor to the BC user forum (mostly 2005-2008).

[Von]

I suggest trying BC 5 (beta).  BC 4 (release) also provides a Hex Compare but not a FLAC Media Compare.  There is definitely a learning curve.  It's worth studying the color codes (summarized in the View menu).

Hi markf2748,

I'm very sorry it took so long for me to respond. Your helpful step-by-step guide is much appreciated!

I have been checking the files in Beyond Compare 5 (beta). Only the audio parts of the files have differences, and this is the block of zeros. All metadata is equal.

Thank you once again for the tip. I enjoy discovering new (to me) and useful software, and will definitely be spending more time with Beyond Compare. 


(Edit: shortened quote.)

[lepa]

I think foobar2000 can also compare audio part between the files. Utilies -> bit compare tracks

[JimH]

Problem solved and reported here:  https://yabb.jriver.com/interact/index.php/topic,138862.msg964940.html#msg964940