Fixing is an absolute must...thank you

Interesting use case @jake ... let me know if it works!

@Anonymous (Johan Kraus) you can do this already using the track number padding rule (https://www.blisshq.com/music-library-management-blog/2011/07/16/padding-track-numbers-with-zero/) or if it's the files that are out of order, use <tracknumber:nn> : https://www.blisshq.com/music-library-management-blog/2011/12/14/new-release-20111206-padding-file-org-acoustic-fingerprints/index.html

This would be great. Sometimes EAC fails to rip a track correctly and I fail to notice, leaving junk audio files in my folders.

anoniem is Johan Kraus

This is a good idea. Exspecially because changing art files and removing them can spoil the flac files easily.

Another suggestion, could the program adjust the tracknumbering and change track 1 tot 01, 2 to 02 ....9 to 09, subsequent the filename from 1 opening to 01 opening

My streamer (lumin) plays in this sequence track 1 10 11 12 13 14 15 16 17 18 19 2 20

Third suggestion change Folder to folder (or folder to Folder)

Yes - this would be really great. I imagine ill be swapping all my ALACs for FLACs to enable it though... (I don't think anyone cares until they loose a few files due to corruption)

Yep, agree with that.

Not sure what you mean by "Once the files are hashed it's easy to detect corruption, but what about before that?" - isn't detection, and alerting of the issue, the end point?

I wonder whether or not we could come up with a way to do a lighthearted test for ALAC corruption, since there's no native support for the feature. Once the files are hashed it's easy to detect corruption, but what about before that? I'm guessing not without some harder work put into analyzing the raw PCM stream for artifacts, which perhaps would be beyond the scope of this.

I guess a step 1 for implementing this would be to add preliminary support to just use FLAC's native checksum while work is being done on implementing the hash of the audio stream for formats like ALAC. This way some people can start testing it sooner.

It's not supported by bliss currently but it's supported for any application that wants to get to it. It's in the METADATA_BLOCK_STREAMINFO header inside a FLAC file. The FLAC command ilne supports using it to test files: https://www.blisshq.com/music-library-management-blog/2015/03/31/test-flacs-corruption/

Yeah, exactly, we just care on whether or not the checksum changes, which it never should. Is extracting the checksum out of a FLAC file trivial/supported?

The more I think about it the more I like this overall idea. Seems to be something a lot of audiophiles want.

It should also have the ability to plug into existing checksums, e.g. FLAC's own.

@Bernardo, in your case (2) would definitely be preferable.

I think this would just be a rule to monitor checksums and alert if one has changed.

I think it could be a very nice addition for bliss to be able to verify library integrity somehow.

I believe that regarding the method for creating a checksum for integrity checks we could go with something out of the usual. It's rather obvious that we don't need this to be cryptographically sound, so algorithms such as MD5 become wasteful. XXHash may be a nice solution, the hashing speed is ridiculously fast, and it should be reliable enough to fit our needs. Although I'm not sure yet, I think the speed difference between MD5 and XXHash won't matter much, the disk speeds will be the bottleneck, although we'll have to wait and see.

Another interesting factor here is how can we store this. I see two ways we can go about this:
1. We checksum the entire file, which means we can't store the sum as a metadata tag, rather we will have to do something like create a large file with song->hash association list.
2. We checksum only the audio data, and here there's the question if we want to sum the formatted data (FLAC, ALAC) or sum over the PCM stream. Not sure why would we do this over the PCM stream, but just putting it on the table.
I for one like solution 2 more. It makes it more portable to just have a builtin sum and it's simpler as well. Although I'm not sure if not summing the metadata could have a negative impact, I think not since bliss will already catch any metadata corruption, I.e. If my artist field gets scrambled or become gibberish. Also, proportionally it is _much_ more likely that a fail would happen in the audio stream as opposed to the metadata.

I don't think the average user would care much for this, but I do feel like an easy way to guarantee integrity throughout your library would be a game changer, current solutions are personal and flimsy. Specially on bliss where it could just be a "Generate sums" button or something like that and a "Check sums" or whatever. I think if this is done right a large share of the Audiophile community could start using it.

I've been talking to another user on email about this. The way he described it really made it sound like it would be a fitting part of bliss. These kind of things are discussed often over at Computer Audiophile.

It fits into the consistency - completeness - correctness mantra - maybe adding a new dimension: integrity or security?!