beaTunes News

Monday, November 7, 2016

Update: beaTunes 4.6.9

beaTunes4 logo

Because of playback problems with some FLAC files, today's update contains a new version of FFSampledSP, which is based on http://ffmpeg.org/ 3.2. Further, the folder-based synchronization has been made more robust, and some other minor things have been added, improved or fixed.

As always, you can download the new version from the download section of the website.

Most important changes in 4.6.9

  • Added mood keywords to embed special fields action.
  • Enforced lowercase ISO-639 language codes.
  • Fixed early abortion of folder-based synchronization.
  • Moved to Java 8u112.
  • Moved to FFSampledSP 0.9.16.

Labels: , , ,

Tuesday, October 11, 2016

Update: beaTunes 4.6.8

beaTunes4 logo

Mostly thanks to user-feedback, today's update fixes a number of little things having to do with showing the right cursor, dealing with filter issues, synchronization artifacts etc. That aside, the most important change is probably, that for now I have dropped support for directly writing to STEM files. Whenever the file manipulation happens via iTunes (in an iTunes-based library), things work as expected. But beaTunes itself will not modify STEM files anymore. It turned out that the library beaTunes uses for MP4 manipulation wasn't able to correctly adjust a certain value for all five streams contained in a STEM, which led to problems when playing the file in Traktor. The problem is understood and fixed, but a newer version of the library that contains the fix is not released yet.

People using MIK made me aware that it uses different tags when writing the initial key into OGG and FLAC files. I have updated beaTunes to make sure that they are imported correctly.

Last but not least, a bug that led to rare application crashes was fixed in both MFSampledSP and FFSampledSP, which is why I updated both libraries.

As always, you can download the new version from the download section of the website.

Most important changes in 4.6.8

  • Added support for MIK-style key tags for OGG and FLAC.
  • Fixed loss of sort order after folder-based library sync.
  • Fixed manually entered ratings shown as computed until sync.
  • Fixed possible disappearing resize cursor for table headers.
  • Fixed display refresh problem when editing inline while a filter is set.
  • Removed some tagging support for stems, due to file corruption issues.
  • Improved automatic iTunes library detection (non-ASCII paths).
  • Improved resilience against Windows COM errors.
  • Moved to MFSampledSP 0.9.7.
  • Moved to FFSampledSP 0.9.15.

Labels: , , , , ,

Tuesday, April 15, 2014

Does 24-bit audio matter?

beaTunes3 logoYou have probably heard of Neil Young's Pono music player. Supposedly it sounds awesome. However, scientists have doubts. The usually very knowledgeable people at Xiph say: Unfortunately, there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48, and it takes up 6 times the space.

The argument against higher sampling rates is clear. And using lossless formats also provides clear advantages–even if it seems like people cannot distinguish between a quality-encoded AAC-file and a CD. But what about the individual sample resolution? Does 24-bit really provide no advantage over 16-bit?

Imagine a very quiet recording, really only using the lower 4 bits out of 16. Will it not sound worse than the equivalent recording using the lower 12 bits out of 24?

I admit, I assumed it will sound far worse. Then I tried the following.

To test, whether it sounds any different, I took an ordinary mp3 file and converted it to 16-bit Wave using sox.

sox rumour.mp3 rumour.wav

Now that we have a 16-bit version, let's create a very quiet version, that uses only the lower 4 bits. That's equivalent to shifting all samples by 12 bits. This is equivalent to multiplying each sample with 1/2^12≈0.00024. As it turns out, this can be easily accomplished using sox:

sox -v 0.00024 rumour.wav rumour_quiet.wav

Now we have a very quiet 16-bit file, really only using 4 bits. Let's do the same for a 24-bit file. To do so, we first convert the 16-bit Wave file to 24-bit. And yes, I know, this does not magically increase the quality, but bear with me for a second.

sox rumour.wav -b 24 rumour24.wav
sox -v 0.00024 rumour24.wav rumour24_quiet.wav

At this point we have two files. One with 16-bit resolution, one with 24-bit. Both are very quiet, but we assume that the 24-bit file sounds better, just because it supposedly still has 12 bits to represent the signal, while the other one only has 4 bits. The fact that we converted from 16 to 24 bits earlier does not matter, because we down-scaled the signal so much by using the -v flag that any disadvantage we might have had is gone anyway.

Well, judge for yourself: rumour_quiet.wav and rumour24_quiet.wav.

Can you tell the difference? I guess the appropriate question is: Are you able to hear anything at all?

That's right. The result is hardly audible, even with great amplification. Now, if you can tell a quality difference between something you can hardly hear and something else you can hardly hear, you astonish me. So unless this little experiment is somehow flawed (please point out any errors!), 24-bit audio does not matter.

Labels: ,