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
1
General Audio / Re: Getting and running fdkaac and opusenc encoders for dbpoweramp and foobar.
Last post by rupeshforu3 -
Sorry for the disguise I am asking lot of questions because previously I mean five years back I have searched a lot to convert MP3 files to other codecs and used various tools but none of them satisfied me and finally I have tried dbpoweramp and after that fully satisfied.

At the starting i have converted MP3 files of size 450gb to other codecs using dbpoweramp. At present I have bought new PC with latest intel processor with Intel hd sound and realtek 897 alc.

Again I want to convert these same MP3 files to other using latest version of fdkaac and opusenc encoders. So I have searched web and compiled myself using msys2.

I have seen the version of opusenc in windows terminal and found that both are same.

I have used four fdkaac encoders one compiled using msys2 and the one provided by dbpoweramp 17.1 and two others downloaded from web.

Two encoders ie., One provided by dbpoweramp and the one downloaded from web are of same size and produced same output m4a file size.

The id tag properties of the m4a file generated by these two encoders are as below

fdkaac 1.0.0, libfdk-aac 4.0.0, VBR mode 1

The other two fdkaac encoders are one compiled by msys2 and the other downloaded from web

The id tag properties of the m4a file generated by these two encoders are as below

fdkaac 1.0.2, libfdk-aac 4.0.1, VBR mode 1

I have played all the m4a files in my android smartphone player and all sounds good.

I think that the fdkaac encoder provided by dbpoweramp is only two months older than the one compiled by msys2 gcc.

If you instruct as "use the one provided by dbpoweramp and discard everything else"  I will follow your instructions.

Or if you instruct as " use the latest fdkaac encoder compiled or downloaded from web and discard the one provided by dbpoweramp" I will follow your instructions.

Finally my request is how to use intel HD audio features and how to use realtek 897 alc during encoding. If these two can't be used strictly say no. I have installed latest drivers for hd audio and realtek 897 alc. I have loaded direct x dsp in dbpoweramp and unfortunately it has detected none.

Please try to read the current post thoroughly and try to reply to my questions

1) Is there any need to use latest fdkaac encoder

2) Is it possible to use intel HD audio and realtek 897 alc during encoding.
2
FLAC / Re: FLAC unicode patch: some help wanted
Last post by Rollin -
I tested 32-bit dll with qaac, refalac, freac and xrecode 3 on 32-bit windows 7 with file named "青木ヶ原樹海-Hliðskjálf-Δ δ-λάμβδα" and it works.
dll also works with SoX (for non-unicode filenames, because SoX itself doesn't support unicode)
4
FLAC / Re: FLAC unicode patch: some help wanted
Last post by doccolinni -
Seems the FLAC maintainer hasn't got time/motivation to work on FLAC. He merged a bunch of PRs on March 15 2021, and his last commits before that are from May 14 2020. Someone else involved with Xiph/Mozilla has merged a few PRs, but the last activity (merging, commenting etc.) by anyone with write access to the FLAC repository has been well over 6 months ago.

Well that's a shame. Might be time for a fork.
6
FLAC / Re: FLAC unicode patch: some help wanted
Last post by ktf -
The point of this discussion is to test the DLL interface for compatibility, so providing an exe would be off-topic and probably derail the discussion.

Seems the FLAC maintainer hasn't got time/motivation to work on FLAC. He merged a bunch of PRs on March 15 2021, and his last commits before that are from May 14 2020. Someone else involved with Xiph/Mozilla has merged a few PRs, but the last activity (merging, commenting etc.) by anyone with write access to the FLAC repository has been well over 6 months ago.
8
FLAC / Re: FLAC unicode patch: some help wanted
Last post by doccolinni -
- UTF-8 on Windows change (which is what this topic is about)
- Compression improvement patch, discussed on HA here
- Bug fix, discussed on HA here
- Fixed subframe speed improvement
- some build system improvement (which made it possible for me to build this DLL with MinGW)

What's taking so long for these to be merged, anyway?

Also, could you provide flac.exe as well instead of just a .dll?
9
General Audio / Re: Directory structure for organizing FLAC files.
Last post by SimBun -
You say you're not having a problem yet you've had to introduce an extra folder layer to alphabetize your tracks to keep the file counts manageable, and no doubt as your collection grows you may need to manually tweak that further depending on how many artists/albums you have fall under each letter (at the moment you have 2 folders for A and 4 for B). What decides where to put the files i.e. do you do it manually, or do you have to maintain some code to handle it for you?
What do you do for Various Artists?

You're also having to use a lot of metadata (including catalog number) in the filenames just to keep them unique.

Whilst I do use albumartist and album as folder names I only use discnumber.tracknumber in the track names because given all the characters that can't be used in filenames they'll never perfectly reflect what I've got in the tags, so what's the point. For albumartist and album I translate (via foobar) the characters that can't be used into the closest unicode equivalent so it at least looks correct, but I have often thought about just hashing them just to make it even simpler.

Would be interested to hear about your experience of using that structure with various software packages.
10
Polls / Re: 2013-21-Lossy-Format-Poll Graph
Last post by doccolinni -
AAC userbase had a large jump.

I don't see this, tbh. The AAC curve looks rather flat, and the fact that it gently wiggles as much upward as it does downward is apparent from the fact that the last datapoint is almost at the exact same height as the first one (at around 25-ish %). The only real "large jump" in these graphs I see is for Opus from 2014 to 2016.

I think it's also worth noting the increase in the last three years of the number of folks saying they don't use lossy as their main audio format. Do we have a trend here, perhaps?

If I had to guess I would say that it's an effect of continued increase of available storage space, but I honestly can't imagine this going very far. The fact of the matter is that no matter how much storage space you have available, a ten-fold (or even twelve-fold) reduction in the amount of storage taken up by your music library will always be a ten(twelve)-fold reduction in the amount of storage space taken up by your music library. Sure, having less storage space available creates an additional pressure to prefer lossy compression over lossless, but something taking up ten or more times more storage space for absolutely no perceptible benefit is equally wasteful regardless of that factor.