On Mon, May 17, 2010 at 2:42 AM, vikas gupta <[email protected]> wrote: > On Sun, May 16, 2010 at 10:40 AM, vikas gupta <[email protected]> wrote: >> On Sun, May 16, 2010 at 7:18 AM, Mohamed Tarek <[email protected]> wrote: >>> The focus in rockbox is really on the codec working properly within the >>> rockbox environment, test programs are generally there because they were >>> needed at the time of importing the codec library. Codecs receive a >>> significant amount of work occasionally, so things like test programs are >>> prone to get broken easily. If the test file isn't working properly in the >>> rockbox simulator on your machine, then it would be nice of you to file a >>> bug. >> >> 1) thanks for the reply. Can't I run the test program on my bare >> solaris box as it is a standalone program or do I require it to be >> tested on Rockbox as my intention was to port the libcook library to >> my hardware and as per FFMpeg dev list, it is good to see how Rockbox >> have done it if I just want libcook to be ported. >> >> >>> >>> Nevertheless, the log indicates that everything is probably working as >>> expected, so you might want to investigate in main.c, specifically the part >>> where the decoded buffers are being written to the output file. >> >> I tried dumping the pcm data from the output buffer in 16 bit format, >> but result is same (broken). I ran the same test file on Ffmpeg, and >> it does provide me the correct output. Am i missing something? > I tried the fixed point svn r 21041 also, but it does give the same > result. Attaching the diff file between the svn code and my built, if > it helps point out the same. > > Regards, > Vikas >> >> Any help will be greatly appreciated. >> >> Regards, >> Vikas >> >
Since your machine is big endian and wav files are little endian, you need to byteswap the samples before they are written to the file, i am pretty sure this is your problem, since the standalone app doesn't do this. Nils
