Rockbox

Tasklist

FS#12371 - FLAC 32 bits 96khz surround 5.1 file not playing

Attached to Project: Rockbox
Opened by Jean-Louis Biasini (JeanLouisBiasini) - Monday, 07 November 2011, 18:52 GMT
Last edited by Andree Buschmann (Buschel) - Wednesday, 14 December 2011, 17:47 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The file is huge, I used it only for testing purpose on the new fuze+ port.
But indeed it doesn't work. See attached little cut of the file.
The screen seems to show that the file get correctly recognized (at least for the bpps) then immediately closed
This task depends upon

Closed by  Andree Buschmann (Buschel)
Wednesday, 14 December 2011, 17:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fxied with r31252, thanks for the support.
Comment by Nils Wallménius (nls) - Tuesday, 08 November 2011, 20:06 GMT
The error comes from the decoder but current ffmpeg can decode it so it's possible it's some bug fixed in ffmpeg since we imported the codec. Otoh i'm not sure how we handle multichannel in flac.
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 13:49 GMT
With the attached patch the file decodes, but I am not sure if the correct two channels are chosen from the 5.1-signal.

Edit: http://flac.sourceforge.net/format.html#frame says that the first two channels in a multichannel set (2-6 channels) are the left and right channel. Therefor this patch should correctly extract the left and right channel out of the 5.1 signal.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 14:39 GMT
On my device (fuze+) this patch leads to (with backtrace patch, and coming from an mp3 dynamic playlist, different compression were tested):
Data abort at 6006BB10
FSR 0x8
(domain 0, fault 8)
address 0x65E85284
backtrace start
pc: 0x6006BB10
sp: 0x60000118
backtrace end

or:

Data abort at 6006BB10
FSR 0x8
(domain 0, fault 8)
address 0x63E74578
backtrace start
pc: 0x63E74578
sp: 0x00005280
backtrace end
this might be related to ( FS#12429 )
Both on test file as on other file of this format I have

if comming from other file format dynamic playlist (ogg and mpc where tested) the player just freeze without any reaction on wps, having deteced correct format and file lengh (one time screen corruption was observed, coming from ogg)
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 14:54 GMT
arf: the second data abort is of course starting with Data abort at 63E74578
meanwhile I just get a third one:

Data abort at 63E712C0
FSR 0x1
(domain 0, fault 1)
address 0xFFFFFFFB
backtrace start
pc: 0x63E712C0
sp: 0x00005280
backtrace end

should I find_address them? And if so I not really sure about the context argument (I mainly always give 1 as in the example given - is it the way to do?)
Comment by Nils Wallménius (nls) - Saturday, 10 December 2011, 16:12 GMT
The dummy array in that patch will not fit on the stack.
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 17:43 GMT
Good point. The updated patch should take care of that,
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 17:59 GMT
Still the same problem from mp3 playlist that must be related  FS#12429  then
If the music is stopped before the patch work.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 18:13 GMT
hum wait I tested 2 complete files they started to play ok and at some random point in the file they get skipped into the next one...
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 18:59 GMT
Just a minor change after checking the code against ffmpeg's code.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 19:16 GMT
no change, sorry... But I can confirm that the data abort also occurs with "normal" flac
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 19:29 GMT
> But I can confirm that the data abort also occurs with "normal" flac

You mean your device has this issue with "normal" (=stereo) flac and the patched decoder? Or does this also happen with svn?
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 19:44 GMT
WOW good point, I kind a forget this! But actually, the data abort seems systematic with any kind of flac coming from mp3 and also occurs in svn... So I've made a new report for this  FS#12442 
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 19:58 GMT
So, the patch fixes the 5.1 playback for you, but you still have another general issue.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 20:02 GMT
no I can't say that because the file get only partialy played and then skipped (anyway with the number of issue with flac file on fuze+ it will be difficult to say. The file should be tested on another device I think) Problem, the files are huge: between 200MB and 300MB each!
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 21:20 GMT
This patch fixes the unwanted skipping for me. Main issue was a too small MAX_FRAMESIZE.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 21:33 GMT
Nice! I confirm this is working here too! But I get ugly compiler warning:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c: In function ‘flac_init’:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:97: warning: assignment from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:98: warning: assignment from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:102: warning: assignment from incompatible pointer type
CC apps/codecs/libpcm/adpcm_seek.c
CC apps/codecs/libpcm/dialogic_oki_adpcm.c
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c: In function ‘decode_frame’:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c:478: warning: passing argument 3 of ‘decode_subframe’ from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c:297: note: expected ‘long int *’ but argument is of type ‘int *’
CC apps/codecs/libpcm/ms_adpcm.c
Comment by Andree Buschmann (Buschel) - Saturday, 10 December 2011, 21:39 GMT
This patch fixes the warnings.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Saturday, 10 December 2011, 21:55 GMT
Tested. Works without problem here, normal flac works too. No more warnings. Good job!
Comment by MichaelGiacomelli (saratoga) - Tuesday, 13 December 2011, 22:47 GMT
A few people have reported that stereo flac files sounds a bit odd with this revision:

<maal> Hi all, i think this commit : http://svn.rockbox.org/viewvc.cgi?view=rev&revision=31207 has broken stereo flac playback.
<maal> I tested on my sansa fuze v2 : r31206 - playback is ok, with r31207 - channels "are mixed" (hard to describe)
Comment by Andree Buschmann (Buschel) - Wednesday, 14 December 2011, 04:01 GMT
I cannot see anything wrong with the changes. w/o any reference file which shows such issue I cannot really proceed on this...

Edit: I already tested two stereo flac files and they have bit-identical output for r31206 (before the latest change) and r31237 (current svn).
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Wednesday, 14 December 2011, 14:27 GMT
see in IRC log the comments of Misanthropos starting at 14:48 on 14th december
Comment by Marek Lawicki (maal) - Wednesday, 14 December 2011, 16:04 GMT
Attached file is played wrong with r31207
   test.flac (1.39 MiB)

Loading...