Skip to main content


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
General Audio / Re: Equalise Volumes via dbPoweramp (-db) & wxMp3gain (+db) conversion
Last post by Markuza97 -
I cannot edit my previous post. Here's a visual guide how to achieve what you are looking for.

Spoiler (click to show/hide)
General Audio / Re: Detecting whether a 24-bit file has been upconverted from 16-bit?
Last post by Abstracter -
I've played-around with some of these tools in the past and they were easy to fool and I recently downloaded Bitter (which I tried in Audacity).     MP3s from ripped CDs show about 30-bits (which is true depending on the MP3 decoder).
bitter can't even survive simple dithering, let alone mp3.
My software cannot survive lossy compression either, but for basic operations like volume adjustment and dithering, it works.

I used your BitSort on some files I suspect were upconverted and got this

00:03:24.2266666 = 18012792 samples / 2-ch @ 44100Hz
24-bit fixed point
Bit   Count         Percent
0   216       0,001199148
1   345       0,001915306
2   580       0,003219934
3   1182      0,006562003
4   2342       0,01300187
5   4654       0,02583719
6   8755       0,04860435
7   15113      0,08390149
8   25147       0,1396063
9   40673       0,2258006
10   62006       0,3442332
11   93798         0,52073
12   139010      0,7717294
13   203963       1,132323
14   327332        1,81722
15   553051       3,070323
16   936168        5,19724
17   1547302      8,590018
18   2421430      13,44284
19   3632266      20,16492
20   4271726      23,71496
21   2934699       16,2923
22   752942        4,18004
23   38092       0,2114719
BitSort end

It's not showing any empty bits but what does it mean when there are bits that have more than 1% of total samples?
3rd Party Plugins - (fb2k) / Re: SACD .dsf file conversion plug-ins
Last post by dbnicholls -
Thanks for all of your inputs.  I downloaded and installed FB2k on my Windows 10 computer and installed the SACD add-ins.  After some minimal learning curve, I was able to successfully convert all of my stereo & multichannel DSF files to WAV.  While I haven't checked out the results in detail, the "multichannel" WAV files are significantly larger than the equivalent stereo WAV files, which are significantly larger than the equivalent WAV files of the equivalent MFSL standard CD.

One thing I did note was that FB2k kept telling me that the conversion process was not "lossless", and I did notice a somewhat smaller file size for a converted WAV file than its source DSF file.  I'm guessing that I am not personally going to notice any difference in audio quality.
General Audio / Re: Equalise Volumes via dbPoweramp (-db) & wxMp3gain (+db) conversion
Last post by Markuza97 -

Only tags are lossless.
All other processes are technically not lossless.
(But they should not affect the quality at all when working with lossless files.)

I am also targeting -14 LUFS myself and I am very happy with it.
-14 LUFS should be equal to 93 dB.

For MP3 files you can simply use foobar2000 to normalize the files directly. This has one disadvantage.
You can only adjust volume in 1.5 dB steps. This is not ideal but it is still better than re-encoding the MP3 files.

If you want to normalize FLAC files you will need to re-convert them into FLAC. Like I said earlier, this is not lossless,
but in reality, there will be no differences, except the volume, of course.

You mentioned WAV files. Why don't you convert them into FLAC to save some space and have proper metadata support?
If you have some huge files you can easily convert everything to 16-bit / 44.1 kHz. Everything above that is really useless.

I have zero experience with MIDI files so I cannot really help you there, sorry.

Edit: I wanted to explain how ReplayGain works so you can understand numbers more easily.

There are two normalization standards.
They are known as "old ReplayGain / ReplayGain Classic" and "new ReplayGain / EBU R128".
Old ReplayGain is targeting 89 dB. New ReplayGain is targeting -18 LUFS.
So 89 dB is equal to -18 LUFS.

By scanning your file, the program will analyze how loud your track is. Let's say that your track is 96 dB / -11 LUFS loud.
Program will then write that your file needs to be adjusted by -7 dB / -7 LUFS.

You can then setup in foobar's playback settings to apply +4 dB / +4 LUFS to target the 93 dB / -14 LUFS.

Think of 89 dB and -18 LUFS as the reference numbers.

Here comes the tricky part. This only applies to specific programs like foobar2000. In other software, the reference point for new EBU R128 is actually -23 LUFS.
So be careful what you are doing.

General Audio / Equalise Volumes via dbPoweramp (-db) & wxMp3gain (+db) conversion
Last post by hmp -
I want to losslessly equalize volumes of my entire music library of mp3s, wavs, FLACs & MIDIs.
Since foobar can't normalize losslessly, I found wxmp3gain can do this to mp3s, but not other audio types.
I discovered that dbpoweramp does it for wavs and FLACs.
FYI: I don't want to simply edit tags for volume equalizing, because I use apps that don't recognize ReplayGain Tags.

I have googled and just simply don't understand the right numbers and how to convert the two db formats to use equalize FLACs in dbpoweramp (via Volume Normalization whilst converting a FLAC to FLAC) to the same level as my mp3s levelled via wxmp3gain.

I want to achieve either 75db, -14 LUFS (Spotify standard), or 89db.
I haven't decided which one because I want to allow enough headroom for clipping and listen to all genres of music.
Once I've chosen a wxmp3gain target (e.g. 75db), since dbpoweramp operates in -db (0 to -40db), whilst wxmp3gain operates in +db (+75db to +105db), how do I convert back and forth from + to - db in dbpoweramp, so that my FLACs and mp3s play at the same volume?

Listening Tests / Re: Personal blind sound quality comparison of Opus hard-CBR with framesize options
Last post by C.R.Helmrich -
OK, I figured it out, and explain here so that Jean-Marc (jmvalin) can read it. For stereo, 56 kbit/s CBR uses a different encoder configuration than for 56 kbit/s VBR, one where the encoder adaptively switches between the speech (Silk) and music (CELT) core. On the applaud sample, the first few seconds are interpreted as speech, and Silk apparently sounds quite a bit worse on applause-like signals than CELT. Using the --music option in Opus's command-line forces CELT throughout this sample. That avoids the problem you describe on this sample but, of course, a more robust speech/music discriminator would be a better solution.

3rd Party Plugins - (fb2k) / Re: SACD .dsf file conversion plug-ins
Last post by Apesbrain -
Just tested and foobar2000 supports DSF 5.1 conversion to multi-channel WAV, FLAC, AAC and OGG.  I could not find a multi-channel encoder for MP3; Fraunhofer once had one in development, but it's no longer on their site.  I didn't test 7.1 as I have no such files.

After resampling to 44100, I also managed to encode the 5.1 WAV to AC3, if that is useful. Here's the test file: (Good for 30 days.)
FLAC / Re: New FLAC compression improvement
Last post by Porcus -
maybe there are still some surprises on 96kHz/24-bit material left.
I said the autoc-double testversion 2021063 -7 was good on hi-rez, this one is even better - on some material. Your new -9 is slooow on this material, good I didn't test the first one.

tl;dr on the below specified four hours of 96/24 (no fancy compression options given!)

-9: spends 40 minutes to achieve 57.25%
-8e spends 15:44 to achieve 57.30% (compared to autoc-double testversion 2021063 it shaves off .31 points at a cost of 8 seconds)
-8: spends 5:36 to achieve 57.33 (savings: 0.38 points, costs 12 seconds). ffmpeg at -8 gets inside that 0.38 interval, no matter whether it uses lpc_order 2 (spending 6:28) or 6 (at 17 minutes)
-7: spends 3:38 to achieve 57.37, which is still better than the autoc-double testversion's -8e
-6: spends 3:11 to achieve 57.83, that is not good compared to -7. Here and down to -4, the differences to the autoc-double testversion is at most .17
-5 spends 2:10 to achieve 57.92. -4 spends 2:00 to achieve 57.98. That's on par with ffmpeg -5, but twice as fast.

I tested CUETools.Flake -4 to -8, not so much variation, spending from 8:27 down to 3:04 for 58.23% to 58.48%.
I tested 1.3.1 at -8 -e (the -e by mistake), took twelve minutes for 58.97 and was worst for all files - except ordinary -8 half a point worse.

But a lot of the improvement is due to an album and an EP out of four. Your new -7 is faster than 1.3.1 -8 and yields savings by half a percent point up to 8.5 (!!) percentage points, and it is the biggest file that is least compressible.

Material: to get done in a day, I selected the following four hours from the above 96/24 corpus, in order of (in)compressibility:

* Kayo Dot: Hubardo. 93 minutes, prog.metal. Needs high bitrate despite not sounding as dense as the next one.
All about the same, all within half a percent point. And this is the biggest file of them all
Best: flake -8 at 65.72, then your new -9 at .73. (Heck, even OptimFrog -10 only beats this by 1 point.)

* Cult of Luna: The Raging River. 38 minutes sludge metal/post-hardcore.
Large variation, flake does not like this.
Best: New -9 at 59.45. -7 and up shaves a full percentage point over the autoc-double testversion. ffmpeg -8 about as good. ffmpeg -5 at 60.8. flake -8 at 62.59, 1.3.1 even a point worse at -8 -e.

* The Tea Party: Tx20. An EP, only 18 minutes Moroccan Roll. Earlier tests reveal: differs significantly between encoding options.
Large variations. Your -9: 53.95. Your -7 beats your new -6 by 3.2 points and your previous -8e by half that margin. ffmpeg varies by 3 points - here is the file where one more lpc pass makes for .1 rather than .02. Flake runs 60 to 61. flac 1.3.1 62 and 63.

* Open Goldberg Variations.  82 minutes piano, compresses to ~47 percent. Earlier tests reveal: doesn't use high Rice partition order.
Best: ffmpeg -8, but between 46.71 and 46.92 except flac -1.3.1 (add a point or more).

Done on an SSD, writing the files takes forty to sixty seconds. Percentages are file sizes without metadata, padding or seektables, but those don't matter on the percentages for such big files anyway.
SimplePortal 1.0.0 RC1 © 2008-2021