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.
Recent Posts
2
Lossless / Other Codecs / MAC (APE) lack of streaming feature - what does it mean?
Last post by krafty -
Hi again folks,

Sorry about this dumb question, but why is it not right to believe that APE does not have streaming feature although I do stream the APE files from a SMB share all the way to the VLC application (using ATV4K box). Does anything happen in this process that VLC transcode on-the-fly the APE into PCM and, with FLAC, it would pass-through directly? If VLC is in fact passing-through the APE file, is it the counting time lag (it delays and updates the timing progress bar each 6 seconds or so) that is bugged so this is not to be considered as a true stream as FLAC or ALAC? Or is it because it might be considered somewhat able to be streamed but not to the point of selling this idea to every and each hardware, because it's quite CPU consuming?

I'd like technical views on this.

Thanks a lot!
4
Support - (fb2k) / Re: Foobar writes non-standard APEv2 tags to my WavPack files
Last post by redrose -
Indeed that looks good.

Here is my example:
https://imgur.com/a/FjqaU5p

It is a compressed DSD file which originally had a ID3 tag.
Maybe it is a bug in the Wavpack encoder, when it encodes a (DSD?) file with ID3 tag, it copies the key names from the ID3 file instead of translating them to the proper APE keys.

After I edited the tags again with foobar, foobar wrote the correct keys.

I must apologize that I blamed foobar, it appears to be not at fault. I will do some further tests and perhaps report it to the WavPack creator. Thank you for your help in any case!
6
Support - (fb2k) / Foobar writes non-standard APEv2 tags to my WavPack files
Last post by redrose -
Problem: when loading WavPack files, all tagged by foobar, into another audio player on my secondary machine, in this case Deadbeef (because Linux), the tags from the WavPack files aren't loaded properly, or so it seems.

Things like artist and title carry over well, but year, tracknumber and total tracks do not. It appears foobar does not adhere to the APEv2 standards when writing tags.

When I look at the APE keys here: https://wiki.hydrogenaudio.org/index.php?title=APE_key , I see for example that according to the APE specification, the year should be put in the tags as key YEAR, but foobar writes under key DATE. Similarly, APE tags require TRACK for the tracknumber, but foobar writes under TRACKNUMBER. Furthermore it uses a separate TOTALTRACKS while APE requires it to be written in TRACK as ##/##. Naturally another program which can read APEv2 tags and expects them to follow the APEv2 specification, does not display these correctly. Deadbeef can see these non-standard tags as custom fields but does not display the tracknumber in the corresponding column. I assume that other software will have this same problem.

What to do? As far as I know foobar does not have an option to write standards-compliant APEv2 tags. What was the reason for this choice? Is it on purpose or by accident? A bug? This makes it very difficult to use a WavPack collection with different audio software.
7
Listening Tests / Re: One year of listening tests: a cross-comparison
Last post by guruboolez -
Does this mean Exhale@96k is a better option than Opus at the same bitrate?
This result is a personal listening comparison. A cross-comparison of different tests to be exact (results of different tests were merged).
I made an opus vs exhale 96 kbps comparison in this test:
https://hydrogenaud.io/index.php?topic=121099.0
Results are a bit more detailed, still in favour of USAC.

I would rather use Exhale than Opus at 96 kbps but this preference is only mine. A public listening test could show different results. I would say that USAC and OPUS are in the same league (a bit like Vorbis and AAC 15 years ago).
9
Lossless / Other Codecs / Re: New lossless codec comparison, categorizing electronic music
Last post by ktf -
I thought it would be a good idea to create a new lossless comparison document.
Big "Yay!", but someone needs to kick the FLAC executives into motion on getting your improvements into the official release.
Well, I tried here and here but no response yet. I also mailed Xiph.org's Monty, but haven't heard from him either.

Quote
so this will not be more than "consider this" - where at least I try not to push my faves all the time:
The problem here is that I really want to be able to have some kind of foundation as to why I'm including certain albums. That's why I'm listing instrumentation. The current list of electronic music has a very basic synths (Game Boy Color emulator), an album with only FM synths, a Kraftwerk album with analog synths... the idea is that differentiating on the source of the sounds used in the music is better than differentiating on something as arbitrary, vague and opinionated as genre. However, I feel unable to differentiate electronic music further then "really simple synth", "FM synth", "analog synth" and "sampling". I don't know what to put in the "Main instrumentation" column for the releases you list.

Quote
Killing more birds with one stone.
Actually, I'd rather have discs that "kill exactly one bird" so it might become a little clearer why a certain codec performs better on that music.

Quote
Then, not what you asked about, but ...

You list a CD table, but then to make it more relevant (at the cost of time & effort, and for the second item: at the risk of lending credibility to the marketing of useless end-user formats):
* Multi-channel?
* High resolution?
There is more available by now. (Also there is much more available for free.)

Yes, very true. However, as using my FLAC testbench showed me that a lot of devices do not support multichannel or high-resolution, I still think most people only use CDDA and that should really stay the focus of comparing.

Still, it wouldn't hurt to expand the multichannel and high-res part beyond what I did last time.