This page describes the changes made in each point release of Niente since its first release as version 4.00 on September 10th, 2024.
Since version 4.00 has only just been released, this page is currently without actual change data. However, pending changes may be listed here, with an indication of when they might make it to public release. Versions with dates attached have been released into the wild and made generally available.
Niente Version 4.02 - Released October 12th 2024
This release implements a bunch of small bug fixes, mostly to do with how the 'non-interactive' Niente operations are performed. For example, if you run the command niente4.sh --check-differential, you'll trigger a non-interactive differential integrity check: non-interactive because the main program window is not displayed as the check is performed. It (and its cousins) are intended for scheduling program functions via crontab. Unfortunately, the necessary environment variables were not being set correctly when these options were invoked and thus not-so-minor things such as extracting the correct bitdepth and sample rates from FLACs were not being performed correctly. I also took the opportunity to add some 'progress dots' to the program output when in non-interactive mode: though you're not likely to see them when the program is run via cron at 3AM, the total lack of progress indication or output hitherto can be a bit unnerving when you're testing things! Now you'll see this sort of thing:
Niente Version 4.01 - Released October 8th 2024
For this first update since it's release, an enhancement has been made to the Niente database, such that it will now contain a column called SAMPLE_RATE in the TRACKS table. Existing databases will have the new column appended to the end of all the existing columns; freshly-created new databases will have the extra column embedded within the other columns. The adjustment to the table structure happens automatically the first time Niente is run after the software upgrade has been applied. Actual population of the new column with data only takes place once a new full, differential or fast integrity scan has been performed. (Note: a Niente database is not particularly significant, since it can be completely re-constructed by doing a fresh database creation, music scan and integrity check. This may take time, but it means the data in a Niente database is essentially fungible. Should you prefer, for example, you could simply delete your existing Niente database, create a fresh one and trigger fresh music scans and integrity checks to get the new column installed and populated 'properly'. It's a fundamental tenet of database normalisation theory, however, that the physical location of a column in a table is irrelevant for working with that table, so Niente won't care whether the new column is integrated within the table structure or appended to it).
SAMPLE_RATE is the counterpart to the BITDEPTH column, which has been there since Version 2 or thereabouts: for any given digital music file, Niente will record it as being '16' or '24' bit-depth as before, but will now also record whether the music has been sampled at 44,100Hz (standard CD Audio), 48,000Hz (enhanced standard CD), 88,200Hz (high resolution digital audio) or even 192,000Hz (bonkers resolution for those with more money than hearing discrimination). Of course, if any other sample rate is detected apart from these 'standard' ones, that will be stored too. This enhancement was suggested by a reader, Scott, to whom I'm grateful for the idea, though it now escapes me why I never considered capturing this data before: its utility is rather obvious, after all! For example, the first thing I was able to do (in sqlitebrowser) was to filter my rows like so:
Here, I'm filtering for recordings which have a 16-bit bitdepth (which you'd normally expect to be standard CD audio) but also have a 96KHz sampling rate (which you'd expect from SACD rips or online high-res sources). That particular combination is so bizarre that I can only conclude that some CD ripping and/or post-processing has 'gone awry' in some way. Not that this is easily fixed, but knowing about this at least means I now know that a re-rip of the relevant CDs is required. Thanks Scott 🙁 ...</joke>
The new data is displayed whenever a Niente database is undergoing an integrity check:
The new line 'Audio Data' displays both the bit-depth and sample rate determined by physical analysis of the digital music file's contents.
To complement this new data collection, a new 'Logical Problems' Report item has been created, displaying digital files for which the sample rates and bit depths don't appear to be sensible combinations.By "sensible", Niente means: if bitdepth is 16, sample rate shouldn't be higher than 48KHz (48,000 Hz); from the opposite way of looking at things, too, if the bitdepth is 24, the sample rate shouldn't be lower than 48KHz.
The new report is accessed from the Logical Issues Reports, Option 6 "Inconsistent Bit Depth/Sample Rates":
The resulting detailed report contains content such as this:
The Aggregate Statistics Report (General Reports, Option 1) has been adjusted to report on the row-count of this report:
The new line on the report is the 'L6' one. Bear in mind that it is at least conceivable that a 24-bit, 44.1KHz recording exists, so that a number on this line of the aggregate statistics report doesn't necessarily represent a real problem (though, personally, I would definitely re-rip to more standard bitdepth/sample rate combos). Niente is just hard-coded to apply the rule that "either 16 bits and sample rate greater than 48KHz; or 24 bits and sample rate less than 48KHz equals 'odd'". I'm open to further enhancement requests if a finer-grained selection of bit depth/sample rate 'problems' is felt necessary 🙂
Finally, a cascading and corresponding change has been made to the 'O3' line on that aggregate statistics report and its equivalent Other Reports, Option 3 Files missing bitdepths in names detailed report. In the original Niente release, the program looked for the bitdepth number in the file name, and if it found it, said 'fine, you've included the bitdepth in the name correctly'. It never actually checked for the presence of the sample rate in the file name at all! It assumed that if "24" or "16" was in the file name, you must have named things correctly including the sample rate. Of course, this meant that a 'Symphony No. 16.flac' would pass the test: if the file was a 16-bit FLAC, the presence of '16' in the file name anywhere would count as a pass (and yes, I knew this was a bit of a hack-job when I wrote it: I was in a hurry, I think!) In light of the new collection of sample rate data for music files, therefore, the rules for this report have been tightened up. The new version of the report knows both the bitdepth and sample rate from the Niente database: it expects them to be concatenated with a hyphen when constructing physical file names (as Semplice, for example, would do for you automatically), so the report now looks for things that don't have text such as '16-44100' or a '24-88200' in their file names. A 'symphony no. 16.flac' would thus now fail the 'do you have bitdepth and sample rates in your filename' test, where previously it would have passed it. Even a file called 'Symphony No. 16. - 44100.flac' would fail, as the program expects 'xxxxx-16-44100.flac' as an absolute pattern, though other bitdepths and sample rates are acceptable, depending on circumstances!)