- 17 Oct, 2015 2 commits
-
-
Rostislav Pehlivanov authored
Long Term Prediction allows for prediction of spectral coefficients via the previously decoded time-dependent samples. This feature works well with harmonic content 2 or more frames long, like speech, human or non-human, piano music or any constant tones at very low bitrates. It should be noted that the current coder is highly efficient and the rate control system is unable to encode files at extremely low bitrates (less than 14kbps seems to be impossible) so this extension isn't capable of optimum operation. Dramatic difference is observable with some types of audio and speech but for the most part the audiable differences are subtle. The spectrum looks better however so the encoder is able to harvest the additional bits that this feature provies, should the user choose to enable it. So it's best to enable this feature only if encoding at the absolutely lowest bitrate that the encoder is capable of.
-
Rostislav Pehlivanov authored
-
- 12 Oct, 2015 1 commit
-
-
Rostislav Pehlivanov authored
To keep it similar to the other functions which are all named *_pred.
-
- 29 Aug, 2015 1 commit
-
-
Rostislav Pehlivanov authored
This commit completely alters the algorithm of prediction. The original commit which introduced prediction was completely incorrect to even remotely care about what the actual coefficients contain or whether any options were enabled. Not my actual fault. This commit treats prediction the way the decoder does and expects to do: like lossy encryption. Everything related to prediction now happens at the very end but just before quantization and encoding of coefficients. On the decoder side, prediction happens before anything has had a chance to even access the coefficients. Also the original implementation had problems because it actually touched the band_type of special bands which already had their scalefactor indices marked and it's a wonder the asserion wasn't triggered when transmitting those. Overall, this now drastically increases audio quality and you should think about enabling it if you don't plan on playing anything encoded on really old low power ultra-embedded devices since they might not support decoding of prediction or AAC-Main. Though the specifications were written ages ago and as times change so do the FLOPS. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-
- 22 Aug, 2015 1 commit
-
-
Timothy Gu authored
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
-
- 21 Aug, 2015 1 commit
-
-
Rostislav Pehlivanov authored
This commit finalizes AAC-Main profile encoding support by implementing all mandatory and optional tools available in the specifications and current decoders. The AAC-Main profile reqires that prediction support be present (although decoders don't require it to be enabled) for an encoder to be deemed capable of AAC-Main encoding, as well as TNS, PNS and IS, all of which were implemented with previous commits or earlier of this year. Users are encouraged to test the new functionality using either -profile:a aac_main or -aac_pred 1, the former of which will enable the prediction option by default and the latter will change the profile to AAC-Main. No other options shall be changed by enabling either, it's currently up to the users to decide what's best. The current implementation works best using M/S and/or IS, so users are also welcome to enable both options and any other options (TNS, PNS) for maximum quality. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-