Print

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

[Von]

This question is not directly related to Media Center, but I hope you don't mind if I ask here anyway.

I experienced something strange when copying several terabytes of FLAC files from a NAS to another drive. I had to pause the operation once and resume it later. I made a note of which file was currently being copied when I hit pause, so that I could make sure that the file had also been copied in the end.

After the process had resumed and finished, the paused file was indeed copied – but I discovered that the copy and the original were not the same size.

Original size: 17 151 686
Copy size: 17 825 792

Both files can be played in Media Center without any problems, and when I convert them to .wav files, the wav files are identical in a file comparison.

Nothing seems to have happened with any other files, it was just the one in process of being copied when I paused the operation.

I have not seen such differences when copying files before, at least not without the copy being corrupt. Does anyone have an idea what may have happened?

[Frobozz]

If you import both versions of the file into MC and do a new audio analysis on both files you can check if the Audio CRC value is the same for both files. If the Audio CRC is the same then the audio data hasn't been altered or corrupted.

The other way the file size could change would be that the tags got altered or modified.

One possibility there is that the file somehow got opened in Microsoft's Windows Media Player Legacy and that program updated the tags. The default settings for Microsoft's Windows Player Legacy is to "Update music files by retrieving media information from the Internet". And that can change the tags. Whenever I set up a new computer I make sure that Windows Media Player Legacy is configured so it does not update music files with data from the Internet.

Or you could have a third-party Windows Shell extension for File Explorer installed that updated the tags in that file.

[Von]

Thanks for your input, Frobozz.

The Audio CRC is identical. I think it would have to be, given that the wav files are identical after converting from FLAC to wav. I checked with the FC command in Command Prompt.

I do not think Windows Media Player Legacy has been involved here. At least, there is no change in the metadata for the file, the date/time for "last edited" is identical for both the original and the copy.

Here is an intereseting bit: All data in Analyze Audio is identical, with the exception of Bitrate. This is slightly higher for the bigger file (the copy). At first I thought this was because bitrate was calculated by file size divided by duration. However, after testing, I see this is not correct. Changing the embedded cover art to a bigger file makes the FLAC file bigger, but it does not change the bitrate in Analyze Audio.

Could extra padding somehow have been added?

[Awesome Donkey]

Check the CRC32 and/or MD5 and/or SHA-256 and/or SHA-512 hashes of both files and see if they're the same. You can use apps like HashTab (this is what I personally use) in Windows or even from the command line/PowerShell get the hash of a file.

If the hashes match but both report different file sizes, this could be due to the file system used on the NAS and the file system used on the other drive being different from each other. If the files were just copied and pasted from the NAS to the other drive, it makes no sense bitrate would change. If they're converted/re-encoded, then it could explain it.

[michael123]

Might be related if the block size on file system partitions differ

[Von]

Check the CRC32 and/or MD5 and/or SHA-256 and/or SHA-512 hashes of both files and see if they're the same.

I have checked MD5, SHA-256 and SHA-512, and the files have different checksums. (I am comparing the "corrupt" copy and a second correct copy, both files now on my Windows 10 computer.)

Might be related if the block size on file system partitions differ

I don't know. The partition formats may be different, but how should this affect one file out of tens of thousands? I copied the files from a Synology NAS to an NTFS drive on my Windows 10 computer. As far as I can tell, this only happened with one file.

[JimH]

Might be related if the block size on file system partitions differ

That was my first thought, too.

674,000 bytes seems too much though.

[markf2748]

Other thoughts:

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?

Maybe you are comparing a Granny Smith apple to a Red Delicious apple?

I don't know of any way to directly determine the compression ratio of an existing FLAC.  If you really want to pursue it, you could re-rip the album using different compression ratios and see which rip(s) match or come close to your old file sizes (if tags are not identical, the file sizes may be a little different).

WAV files may have less header info than FLAC files.  If there are header differences or music section compression differences in your FLACs, they might still get converted to identical WAV files, as you report, especially since FLAC audio compression/decompression is lossless.

[JimH]

The difference in size is more like a lower resolution image file.

[JimH]

Split Comparing Two Files

[Von]

Hi,

Sorry for taking so long to follow up, things suddenly got very busy for me elsewhere.

Other thoughts:

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, this is not the case. There is only one version of the track.

After comparing the files (more on this in the other thread: https://yabb.jriver.com/interact/index.php/topic,138882.0.html), my conclusion is that there are no other differences between the files than added padding in the "corrupt" copy.

Why the copied file was changed like this, I don't know. Of course, this had nothing to do with JRiver Media Center.

As I said in my first post, when converting the original (a fresh copy, to be exact) and the corrupt copy to wav, the resulting files are identical.

I find it interesting that Analyze Audio shows different bitrates for two FLAC files with identical audio content. The bitrates are 854 for the copy and 821 for the original. If someone at JRiver would like to look at the files, just let me know.

[markf2748]

After comparing the files (more on this in the other thread: https://yabb.jriver.com/interact/index.php/topic,138882.0.html), my conclusion is that there are no other differences between the files than added padding in the "corrupt" copy.
...
I find it interesting that Analyze Audio shows different bitrates for two FLAC files with identical audio content. The bitrates are 854 for the copy and 821 for the original. If someone at JRiver would like to look at the files, just let me know.

Percent differences based on what you report, relative to the smaller, original file:

Total file size: (17,825,792 / 17,151,686) -1 = 3.93%
MC Analyze Audio bit rate:  (854 / 821) -1 = 4.02%

If you were to do the file size calculation based on omitting metadata, but including the large zero block (preceding music) plus audio, I suspect the correlation of the two percentages would be even closer.

I assume Analyze Audio's reported bit rate is some kind of average of total bytes over the playing time (in real time the bit rate continuously changes as displayed in the Player Bar).  All this suggests that MC's Analyze Audio bit rate includes the padding zero block, and hence does not reflect bit rate for the played music alone.

It would also be interesting to know what bitrates foobar2000 reports for your two files.

Thanks for reporting back, and glad to hear you learned something about the details from BC !   

6/27/2024 Edit conclusion.

[Von]

It would also be interesting to know what bitrates foobar2000 reports for your two files.
6/27/2024 Edit conclusion.

After importing the files, foobar2000 says the bitrate is 854 for the copy and 822 for the original. I'm not sure if this is foobar2000 reading existing file information, or if the program has performed its own analysis. I'm not familiar with how foobar2000 works.

[markf2748]

After importing the files, foobar2000 says the bitrate is 854 for the copy and 822 for the original. I'm not sure if this is foobar2000 reading existing file information, or if the program has performed its own analysis. I'm not familiar with how foobar2000 works.

Thanks for that.  We are pretty far down a rabbit hole, but here's what I've learned:

On a random FLAC track selected from my library, MC and foobar2000 report the same bitrate (as does Mp3tag).  You have also confirmed that the two programs essentially agree.  But what the heck is the meaning of "bitrate" and how is it calculated?

I am guessing all these programs depend on a third party FLAC utility library to read FLAC files.  In any case, as a DIY end user, one can download the free FLAC command line utility metaflac.exe from xiph.org https://xiph.org/flac/documentation_tools_metaflac.html.  Here's the output on my test file for Block 0 of the Audio Data, which is the STREAMINFO block, run in a Windows Command Window or PowerShell:

Code: [Select]

PS C:\xxx\xxx\flac-1.4.3-win\Win64> ./metaflac.exe --list --block-type=STREAMINFO ".\test\xxx xxx.flac"
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 14 bytes
  maximum framesize: 13372 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 12038712
  MD5 signature: 599eb5eadc40d7e6b4c83cb0dab0b885Most of this output is reported by MC (Tag Pane > Tag Dump), foobar2000 (RMB on track > Properties), and other programs.  Using this data, here is the track duration reported by programs:

Duration (per channel) = (total samples per channel)/sample_rate = 12,038,712 / (44,100 Hz) = 272.987 s = 4 min 33 s.

From PowerShell dir command:
File size = 32,283,646 bytes = (32,283,646 bytes)*(8 bits/byte) = 258,269,168 bits.

The FLAC compressed Audio Data size is smaller than the total file size:
Audio Data size (reported by BC5 (beta)) = (31,805,199 bytes) * (8 bits/byte) = 254,441,592 bits.

Bitrate (total 2-channels combined) = (Audio Data size) / Duration = (254,441,592 bits) / (272.987 s) = 932.065 kilobits/s

Both MC and foobar2000 report bitrate = 932, in agreement with this calculation!

I don't know what file operations the programs use to acquire the Audio Data size.  Here I depend on BC5 to do a Media Compare of the file with itself, which reports size of Audio Data in bytes.  I get exactly the same size when I count from first to last hex audio byte (based on first and last hex byte addresses following the big zero padding block).

Note:  It is perhaps puzzling that (total samples)*(bits-per-sample)=192,619,392 bits is smaller than Audio Data size.  The reason is that the the former is just raw single channel, while the latter includes 2 compressed channels.

To answer my own question:  Apparently bitrate is the average FLAC bitrate over the duration of the track for decompressing 2 channels of FLAC audio data, in kilobits/s (note: in this example, the FLAC decoder will use the real-time compressed data to restore the original 41,100 Hz 2-channel 16-bit audio signal, lossless, before sending it out to a DAC).

Perhaps someone more experienced in these matters could confirm above. Most likely, the extra zero bytes in the copied (larger) file are being counted as part of the Audio Data, while the STREAMINFO remains unchanged, causing the programs to return a proportionately higher bitrate for the copied file.   I believe I've provided everything needed for @Von to further investigate the bitrate difference between the two subject files, if so inclined.   

6/28/2024 Multiple edits through the day for clarity.for