Lossless encoders - unexpected increase in bitrate

Topic: Lossless encoders - unexpected increase in bitrate (Read 7021 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Lossless encoders - unexpected increase in bitrate

2010-04-23 04:04:05

Hi all,

I'm confused as to why a lossless track has increased in size after data has been removed. Can someone explain why the bitrate has gone up.
Here's the process and below that are the bitrates of the files in FLAC and TAK along with samples.

Original = 30 sec segment from Faure's Nocturne No.1 in E flat minor, 1956 recording. Signal goes up to 22 kHz.
Processing (Cool Edit Pro) - Hiss reduction > gentle roll-off filter from 16 kHz to 20 kHz > Channel Mixer Average (mono output).

I expected this to reduce the bitrate. However bitrates went up for both FLAC and TAK:

Original TAK = 272
Processed TAK = 303
Removed Noise (Inverted Mix Paste) TAK = 306

Original FLAC = 305
Processed FLAC = 321
Removed Noise (Inverted Mix Paste) FLAC = 313

The 30 sec files in FLAC format are:
faure_nocturne_01_original_30secs.flac
faure_nocturne_02_processed_30secs.flac
faure_nocturne_03_difference_inv_mix_paste_30secs.flac

Can anyone explain why the bitrates have gone up since 2 kHz of HF data no longer needs to be encoded and the strength of the HF signal from 16 kHz upward is greatly reduced etc ...

Any help much appreciated,

Thanks

C.

EDIT: minor edit of last sentence for clarity.

Lossless encoders - unexpected increase in bitrate

Reply #1 – 2010-04-23 15:57:46

Original file is mono.

I copied the left channel of the processed file to the right channel: 227 kbps for FLAC -5.

Apparently Cool Edit Pro adds different dither noise to left and right channels.

Lossless encoders - unexpected increase in bitrate

Reply #2 – 2010-04-23 16:11:05

Ah, so Cool Edit's Channel Mixer > Average 50% either channel doesn't result in true mono. Is that what you're saying it applies dither differently to left and right and thus doesn't result in a true mono file (with 2 channels).

If that's the case what's the best way to get left & right channels identical in Cool Edit (outside of using "open as" mono and then splitting that to left and right)?

Thanks lvqcl

C.

EDIT - clarity and grammar.

Lossless encoders - unexpected increase in bitrate

Reply #3 – 2010-04-23 18:19:47

Okay I can answer my own question, which leads me to another.

New process works:

[1] Convert to 32 bit float >
[2] Hiss reduction >
[3] gentle roll-off filter from 16 kHz to 20 kHz >
[4] Convert Sample type to 16 bit mono (applies dither) >
[5] Convert Sample type to 16 bit stereo (no dithering applied / required, simply splits the channels) =

Now I have my truely MONO file in 2 channels and the bitrate of the TAK encode is down by 60 kbps from the original, which is what I expected. So thanks again lvqcl.

One question: Is there really any benefit from going to 32 bit float to do stages [2] and [3]?

Cheers,

C.

Lossless encoders - unexpected increase in bitrate

Reply #4 – 2010-04-23 20:12:41

Quote

One question: Is there really any benefit from going to 32 bit float to do stages [2] and [3]?

I'm not sure about Cool Edit, but most audio editors convert everything to 32-bit float for internal/temporary processing anyway. (From what I've read, DSP is easier to do in floating-point than in integer.)

Lossless encoders - unexpected increase in bitrate

Reply #5 – 2010-04-23 20:40:28

Result of audio processing algorithms usually cannot be represented in integers.

I too think that CoolEdit converts 16 bit sound to 32 bits, performs operations, and requantizes output back to 16 bits (thus adding quantization noise).

Lossless encoders - unexpected increase in bitrate

Reply #6 – 2010-04-23 20:52:00

Quote from: carpman on 2010-04-23 18:19:47

[5] Convert Sample type to 16 bit stereo (no dithering applied / required, simply splits the channels) =

Why do you need this step? I don't know about TAK, but FLAC supports a true mono file where only one channel of data is stored in the file. I did this when transferring some mono lps.

Lossless encoders - unexpected increase in bitrate

Reply #7 – 2010-04-24 00:42:13

Quote from: lvqcl on 2010-04-23 20:40:28

I too think that CoolEdit converts 16 bit sound to 32 bits, performs operations, and requantizes output back to 16 bits (thus adding quantization noise).

That suggests I am better off converting the file initially to 32 bit float since that would prevent Cool Edit Pro requantizing output back to 16 bits after each process -- does that make sense?

@ maggior, thanks for the suggestion. But so far I've not found anything related to mono switches for TAK and that's what I use. Furthermore since these kind of processing jobs are done in batches it's not too much hassle I just leave CEP to it.

Thanks for all the input, much appreciated.

C.

Lossless encoders - unexpected increase in bitrate

Reply #8 – 2010-04-25 16:53:03

Sorry to bump this, perhaps prematurely, but does anyone know the answer to this:

Quote from: carpman on 2010-04-24 00:42:13

That suggests I am better off converting the file initially to 32 bit float since that would prevent Cool Edit Pro requantizing output back to 16 bits after each process -- does that make sense?

Thanks,

C.

Lossless encoders - unexpected increase in bitrate

Reply #9 – 2010-04-25 16:57:52

Quote from: carpman on 2010-04-25 16:53:03

Sorry to bump this, perhaps prematurely, but does anyone know the answer to this:
Quote from: carpman on 2010-04-24 00:42:13
That suggests I am better off converting the file initially to 32 bit float since that would prevent Cool Edit Pro requantizing output back to 16 bits after each process -- does that make sense?

Thanks,

C.

I would be very surprised if any audio editor kept converting back to 16 bit at every intermediate step just because the original was 16 bit. I don't think there is an issue here.

Lossless encoders - unexpected increase in bitrate

Reply #10 – 2010-04-25 17:48:33

Okay, I think I misinterpreted this from lvqcl:

Quote from: lvqcl on 2010-04-23 20:40:28

I too think that CoolEdit converts 16 bit sound to 32 bits, performs operations, and requantizes output back to 16 bits (thus adding quantization noise).

Thanks pdq. That's everything cleared up for me.

C.

Lossless encoders - unexpected increase in bitrate

Reply #11 – 2010-04-25 18:23:16

Quote

That suggests I am better off converting the file initially to 32 bit float since that would prevent Cool Edit Pro requantizing output back to 16 bits after each process -- does that make sense?

Yes, this makes sence.

Quote

I would be very surprised if any audio editor kept converting back to 16 bit at every intermediate step just because the original was 16 bit.

Well, Adobe Audition 1.5 (ex-CoolEdit) does exactly this. And it has an option "Dither Transform Results (increases dynamic range)":

Quote

Enables dithering when processing effects such as FFT Filter or Amplify. Most processing done by Adobe Audition uses arithmetic greater than 16-bit, with the results converted back to 16-bit when complete.

Lossless encoders - unexpected increase in bitrate

Reply #12 – 2010-04-27 03:11:33

Thanks lvqcl.
I know it's better to work in 32 bit float, so I've always initially converted 16 bit to 32 bit before processing anyway, however now I know why that's a smart move. Though, what pdq said makes sense, since internal processes are 32 bit float anyway, I'm surprised there isn't an option in Cool Edit to only requantize output back to 16 bits on final save. That said the developers made the program nice and manual, so if you want to work in 32 bit then convert to 32 bit.

Anyway, thanks to all who replied. It's cleared up 2 issues for me:

1) Why it's sensible to initially convert to 32 bit float
2) Don't trust CEP's channel mixer to make a 2 channel mono file; instead as a final step, convert sample type to 16 bit mono (applies dither) then convert back to stereo at the same bit-depth (obviously).

Thanks again,

C.

EDIT: minor grammatical edits

Lossless encoders - unexpected increase in bitrate

Reply #13 – 2010-04-27 20:31:43

DAWs and Audio editors prepared to work with big files tend to work on disk, not on RAM.

Think about this scenario: 12 stereo tracks (drums, singer, chorus, guitar,....), at 24bit 96Khz for a duration of 5 minutes.

That's 24 channels * 288Kbytes/s * 300 seconds ~ 2GB (yes, with G). This is why tradeofs like using the file's original bitdepth and samplerate may apply.

Notice