Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Track file size changed after cuetools fix (Read 2240 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Track file size changed after cuetools fix

Hello

I sometimes uses cuetools in order to repair slightly damaged rips.

When I run cuetools to repair an entire CD rip, but with just one track in error, the size of all the files
change. And the file size change can be a few hundred of KBytes !

Is there an explanation for that : is it only the tagging space use in the files ?

Thank you for your answer. I hope I've been clear enough

linuxgalere

 

Re: Track file size changed after cuetools fix

Reply #1
CUETools will encode again (losslessly, so that is no problem but for the time it takes).

Say you are using FLAC, try to drag the slider to 0 and to 8 and see the difference.

Re: Track file size changed after cuetools fix

Reply #2
Code: [Select]
metaflac --show-md5sum *.flac
Shows the stored (calculated during the creation of the flac file) md5 hash of the decoded audio in the flac file, so no matter what compression you use it should always be the same. In your scenario, if you ran it before and after a fix only the track that was fixed should change.

Code: [Select]
flac --test *.flac
Can be used to check that the stored MD5 still reflects the decoded audio. This shouldn't be necessary in your scenario, but is useful if you want to check for potential bit-rot of the audio data.

Re: Track file size changed after cuetools fix

Reply #3
If you want to do this kind of exercise, it is probably easier to dump the "before" and the "after" into foobar2000 and user the foo_bitcompare component. Especially since one can also use CUETools to fix offset (shifting the bitstream to the left or right), an operation that moves audio in between files and thereby does alter the MD5.

Re: Track file size changed after cuetools fix

Reply #4
@Porcus
I was not only giving @linuxgalere a simple way to compare the audio of flac files using the native flac methods, but hopefully educating them about the fact that there's a hash of the audio data contained in the FLAC metadata itself.

If you want to do this kind of exercise, it is probably easier to dump the "before" and the "after" into foobar2000 and user the foo_bitcompare component.
Given that this is probably just a one off learning exercise, I doubt unzipping metaflac is harder than installing and configuring foobar and bitcompare!

I'm struggling here, but what is a real life use case for that component? We have AccurateRip and CTDB to verify files/rips, and you can run a test against a FLAC to see if the audio is still correct (that it matches the stored MD5), so what do people use this for?

Re: Track file size changed after cuetools fix

Reply #5
Thank you all for your replies. mine is quite late... I'm not working on that everyday, I apologize.

In reply to SimBun,
The command metaflac --show-md5sum *.flac gives the same md5 hash for all the files (except of course the file corrected), before and after cuetools repair

In reply to Porcus,
The flac compression ratio is 5 in EAC (v1.6), and it was the same in cuetools
I tried changing the flac compression slide : the difference vary slightly, but far from the 200KB difference for a 37MB flac file.
But Flac codec was cuetools (embedded ?) by default in cuetools.
I switched it to libflac, and the file sizes approaches, anyway with a slight difference for each file ...

Is there a best choice for the codec. I may suppose they are all equals ?

Re: Track file size changed after cuetools fix

Reply #6
* Open both in foobar2000 and read off bitrate. How much do they differ?
* For each, select Properties and hit the Artwork tab. How much do picture sizes differ?
* There might be padding after removing artwork. To eliminate that (warning: subsequent retaggings may be slow because then the whole file might have to be rewritten!):
Shift-rightclick -> Utilities -> Optimize file layout + minimize file size
Compare sizes then?

You can also remove everything but audio (hence step 1, you really don't want this except in order to compare) using metaflac as follows:
1: Copy both into a new folder called 'throwaway'.
2: Open a command window there.
3: Give command metaflac.exe --dont-use-padding --remove-all *.flac
3: Compare sizes again.

Re: Track file size changed after cuetools fix

Reply #7
Much more easy when I get an email while the post is updated !

All artwork files have the same sizes
Original file (eac libflac 1.3.2  compression 5) : 940 Kbps   file size 38 416 866 bytes
After cuetools (with cuetools 2.1.9 compress 5) : 935 Kbps  file size 38 221 010 bytes
After cuetools (with libflac 1.3.3 compression 5) : 940 Kbps file size 38 422 177 bytes

->we can see that libflac differs  in cuetools and eac

After Optimize file layout + minimize file size
Original file (eac libflac 1.3.2  compression 5)  file size 38 408 670 bytes
After cuetools (with libflac 1.3.3 compression 5) file size 38 408 861 bytes

Still 191 bytes.
I'm not sure there has been differences in compression algorithm between libflac 1.3.2 and 1.3.3
But I see at least one difference in tagging : eac tags the TOTALDISCS information , cuetools not

Re: Track file size changed after cuetools fix

Reply #8
And ... after removing everything
Original file 38 327 727 bytes
After cuetools 38 327 890 bytes

Still 163 bytes bigger after CT

MD5 checksum is exactly the same

The only explanation is the difference between libflac

I'll look how do we update libflac in EAC

Re: Track file size changed after cuetools fix

Reply #9
OK, understood !
Files created with libflac 1.3.3 are slightly bigger than 1.3.2

Thank you for your help !

Re: Track file size changed after cuetools fix

Reply #10
Different builds need not produce precisely the same FLAC files. If you try FLAC 1.3.0 vs 1.3.1, you would see much bigger differences.

There is also no reason that a higher version should produce smaller files at a given preset.  One upgrade made -8 considerably faster, but would on some material produce bigger files.