IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
HE-AAC gapless playback
nu774
post Dec 22 2012, 17:36
Post #1





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



I knew that Apple and other software (at least fb2k and winamp FhG encoder) treats delay of HE-AAC differently.
In short, fb2k can play FhG's HE-AAC gaplessly, and iTunes can play Apple's HE-AAC gaplessly, but fb2k cannot play Apple's HE-AAC gaplessly, etc.

Personally I'm not using HE-AAC for music so I didn't care much about it so far.
However, just out of curiosity, I looked into it further today.

In ISO 14496-24:2008 (which you can read from the link at http://wiki.multimedia.cx/index.php?title=AAC), it is written that additional decoder delay introduced by SBR tool is 481 (which becomes 962 in upsampled scale).

Then I tried trimming the first 962 samples of the decoded wav file (encoded by Apple then decoded by fb2k), and I noticed that offset matches with the original.
Next, I made hacked version of qaac, which basically do the following:
  1. Append silence of 2048 samples to the end of input before sending to encoder
  2. Add 481 to encoder delay of iTunSMPB, and also edit other values

Using this hacked version of qaac, now I could get gapless HE-AAC playback on fb2k.
So, my guess is the following:
  1. fb2k doesn't trim additional decoder delay introduced by SBR tool
  2. Winamp FhG encoder count this additional decoder delay into encoder delay of iTuneSMPB

Why all of this is happening? Is this correct?

This hacked qaac and used test files are in the attached file:
Files under CAF and M4A_2112 are unmodified HE-AAC files (You can play this CAF file gaplessly using my foo_input_caf).
Files under M4A_2112+481 was encoded using hacked qaac.
Attached File  HE_AAC_Gapless.zip ( 1.26MB ) Number of downloads: 205


This post has been edited by nu774: Dec 22 2012, 18:25
Go to the top of the page
+Quote Post
nu774
post Dec 22 2012, 18:11
Post #2





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



As I did it, trimming required by gapless playback can be achieved by counting this as the encoder delay (Although it is some kind of a hack or cheating).
However, I think it is quite problematic if it actually is a decoder delay produced by SBR decoding, since HE-AAC can be decoded as LC-AAC (ignoring SBR part), in which case this additional delay will not appear.
Go to the top of the page
+Quote Post
benski
post Dec 22 2012, 20:06
Post #3


Winamp Developer


Group: Developer
Posts: 670
Joined: 17-July 05
From: Brooklyn, NY
Member No.: 23375



The Winamp code for adding the iTunSMPB writes the total encoder+decoder delay, yes. And the playback code also assumes that iTunSMPB includes total delay. That's what was done for iTunes AAC LC, but I have not updated this code since iTunes added support for HE-AAC.

I will investigate the iTunes implementation and see what delay is written and whether it includes SBR delay or not. It does raise the question of what to do about old files with the wrong delay value, but since the delays are fairly standard it can be easily detected and corrected for.

Thanks for passing along the information; wouldn't have known about it otherwise.
Go to the top of the page
+Quote Post
kode54
post Aug 14 2013, 02:41
Post #4





Group: Admin
Posts: 4664
Joined: 15-December 02
Member No.: 4082



Extra add for this, the XLD encoder plug-in based on fdk-aac has the same problem with SBR. I found that subtracting 481 from the delay written to SBR files worked perfectly, but not so for SBR+PS. It seems SBR+PS need to subtract 391 from the combined delay given by the encoder instead.

EDIT: Scratch that, I was using Jack rerouted output instead of actually converting the files. Seems like 481 is correct for PS as well.
Go to the top of the page
+Quote Post
nu774
post Oct 26 2013, 11:27
Post #5





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



And my extra add about this:
https://sites.google.com/site/qaacpage/news...se225refalac125

As a workaround, I just appended one frame length silence, but it might be better to try smart padder of opus (using LPC).
Go to the top of the page
+Quote Post
nu774
post Oct 26 2013, 11:36
Post #6





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



Since iTunSMPB includes decoder delay of LC-AAC (1024), I guess Apple doesn't includes additional decoder delay of SBR (481) purely for compatibility reason with LC only decoder.
Go to the top of the page
+Quote Post
kode54
post Oct 26 2013, 12:04
Post #7





Group: Admin
Posts: 4664
Joined: 15-December 02
Member No.: 4082



foobar2000 v1.3, which is now in beta, handles iTunes encoded files correctly now, at least as long as they don't exhibit the bug you just described.
Go to the top of the page
+Quote Post
nu774
post Oct 26 2013, 13:24
Post #8





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (kode54 @ Oct 26 2013, 20:04) *
foobar2000 v1.3, which is now in beta, handles iTunes encoded files correctly now, at least as long as they don't exhibit the bug you just described.

Oh, nice to hear that. Then it might better to fix fdkaac. It still uses the value returned from FDK encoder.
Go to the top of the page
+Quote Post
sluggy
post Oct 26 2013, 17:06
Post #9





Group: Members
Posts: 59
Joined: 22-June 12
Member No.: 100900



Does that mean that fhgaac now needs to be updated for HE-AAC to be played correctly in fb2k and itunes?
Go to the top of the page
+Quote Post
nu774
post Oct 26 2013, 17:16
Post #10





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (sluggy @ Oct 27 2013, 01:06) *
Does that mean that fhgaac now needs to be updated for HE-AAC to be played correctly in fb2k and itunes?

Unless fb2k implements some conditional trick specific on encoder, yes.
Go to the top of the page
+Quote Post
kode54
post Oct 26 2013, 20:55
Post #11





Group: Admin
Posts: 4664
Joined: 15-December 02
Member No.: 4082



Or unless the fhg encoder already uses Nero chapters, which will be preferred over the iTunSMPB tag.
Go to the top of the page
+Quote Post
nu774
post Oct 27 2013, 15:17
Post #12





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



Added --include-sbr-delay option to fdkaac, for controlling SBR decoder delay treatment.

Also found some oddity in iTunes AAC decoder.
I had to finally upgrade iTunes only to confirm if these issues are still there... and as I was afraid, nothing seems to have changed from 10.5.3.
Go to the top of the page
+Quote Post
sluggy
post Oct 30 2013, 20:19
Post #13





Group: Members
Posts: 59
Joined: 22-June 12
Member No.: 100900



[fdkaac] 0.4.2
posted 8 hours ago by nu 774
I found gapless playback issue on this sample when encoded with SBR (not annoying, but tiny pop is audible), so implemented improved gapless playback by the method used by Vorbis and Opus (extrapolation by linear prediction). Extrapolation is done both at beginning and ending, since ending only extrapolation didn't fix the issue on this sample.

Also, this version adds one extra zero sample at beginning in case of SBR+PS, since FDK-AAC has odd enc_delay for SBR+PS, which cannot be exactly expressed in downsampled time scale (which is mandatory for iTunes compatibility).

In order not to increase amount of enc_delay and padding, one AAC frame is discarded from each of beginning and ending, to compensate the padding added on our side.

To tell the truth, qaac has the same gapless issue when encoded with --he. However, I'm wondering if I should implement the same padder on qaac, since it will make the result no more identical with iTunes (or other Apple softwares).

Go to the top of the page
+Quote Post
eahm
post Oct 30 2013, 22:15
Post #14





Group: Members
Posts: 1161
Joined: 11-February 12
Member No.: 97076



QUOTE (sluggy @ Oct 30 2013, 12:19) *
To tell the truth, qaac has the same gapless issue when encoded with --he. However, I'm wondering if I should implement the same padder on qaac, since it will make the result no more identical with iTunes (or other Apple softwares).

Thanks for the update and crazy about iTunes, is Apple every reading here? Are they going to fix this as well?
Go to the top of the page
+Quote Post
nu774
post Oct 31 2013, 02:29
Post #15





Group: Developer
Posts: 562
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (eahm @ Oct 31 2013, 06:15) *
QUOTE (sluggy @ Oct 30 2013, 12:19) *
To tell the truth, qaac has the same gapless issue when encoded with --he. However, I'm wondering if I should implement the same padder on qaac, since it will make the result no more identical with iTunes (or other Apple softwares).

Thanks for the update and crazy about iTunes, is Apple every reading here? Are they going to fix this as well?

It may not be nice, but I don't think it is a BUG.
It seems that SBR is weaker against cliffs at beginning/ending than LC, but I'm no specialist and don't have any technical clues.
Go to the top of the page
+Quote Post
Maurits
post Oct 31 2013, 13:21
Post #16





Group: Members
Posts: 402
Joined: 30-September 05
From: London, Europe
Member No.: 24805



QUOTE (eahm @ Oct 30 2013, 22:15) *
QUOTE (sluggy @ Oct 30 2013, 12:19) *
To tell the truth, qaac has the same gapless issue when encoded with --he. However, I'm wondering if I should implement the same padder on qaac, since it will make the result no more identical with iTunes (or other Apple softwares).

Thanks for the update and crazy about iTunes, is Apple every reading here? Are they going to fix this as well?

I know of at least two senior Apple developers who occasionally used to pop up in relevant topics on HA. I doubt they'll read every topic that might have some relevance to Apple though...
Go to the top of the page
+Quote Post
poiko
post Jun 17 2014, 07:41
Post #17





Group: Members
Posts: 3
Joined: 30-November 05
From: Tampere, FINLAND
Member No.: 26110



I have been contact with Apple regarding this issue and also wrote to their support forum. (https://discussions.apple.com/thread/6397997)

The Apple implementation for HE AAC gapless is bad.

Winamp, Foobar, and EZ CD Audio Converter use the same kind of gapless information which is the actual number of samples for encoder delay and total samples not just the AAC LC part as Apple does.


--------------------
Developer
POIKOSOFT
http://www.poikosoft.com
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th November 2014 - 11:31