Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Siaoru - 2009-01-10
Last edited by Buschel - 2011-02-03

FS#9776 - WMA Decoder - Problematic Files with example

Dear all :)
I find some problem files for WMA decoder in the attached.

115.I.COULD.BE.THE.ONE.wma fails to play correctly in the beginning.
this file format as following:
Windows Media Audio 9.2
bitrate : 5 kbps, sample rate : 8 kHz, mono (A/V) 1-pass CBR

07.Devil.In.My.Mind.wma, I hear some noises.
This file format as following:
Windows Media Audio 9.2
bitrate : 32 kbps, sample rate :44.1 kHz, stereo 1-pass CBR

Could you fix these bugs for WMA codec?

Thanks you!

Closed by  Buschel
2011-02-03 11:06
Reason for closing:  Works For Me
Additional comments about closing:  

Both attached files work fine using r29209.

Neither of those files decodes quite right in ffmpeg, so fixing them is probably beyond me (though you may want to report them to ffmpeg to see if they have any ideas).

That said:

115.I.COULD.BE.THE.ONE.wma blows up while parsing the headers, but the same code works in ffmpeg, so its probably some sort of difficult to trouble shoot parser problem.

07.Devil.In.My.Mind.wma seems to have some sort of overflow from time to time. I will try to figure out whats wrong with this file.

Dear MichaelGiacomelli,
About file 115.I.COULD.BE.THE.ONE.wma, I find that it fail because (s→block_pos + s→block_len) > s→frame_len when decoding wma_decode_block( ),
but it return success when goes to asf_parse_header( )
Is the unstandard format bitstream lead to this situation ?

Thank you very much!

About file 115.I.COULD.BE.THE.ONE.wma, I find that it fail because (s→block_pos + s→block_len) > s→frame_len when decoding wma_decode_block( )

I’ve seen this problem before. I have no idea what causes it, but I assume it is because we are not properly feeding the decoder with the right data. The condition errors out because its not allowed to have block that spans a frame boundary. Since ffmpeg uses the same code here, and does not error out, I assume it means there is a problem in the rockbox asf parser (which is not based on ffmpeg).


											

Dear MichaelGiacomelli,
I find out the bug of the file “115.I.COULD.BE.THE.ONE.wma”, it has an informal replicated length in asf_read_packet.
Skip one byte if replicated_length equal to one!
Detail in the attached.

Regards,
Siaoru

   wma.c (19.1 KiB)

Great work!

If you give me your name I can credit you in the SVN commit.

My name is “Siaoru” in the Rockbox.

Thank you!

If you want credit you’d have to give me your real name, not the user name on this tracker.

My real name is “Siaoru Lee”, but I just register it on Rockbox only. How to register it on SVN ?
Thank you !

My real name is “Siaoru Lee”, but I just register it on Rockbox only. How to register it on SVN ?
Thank you !

Thank you. I’ve committed a simple note with the fix saying that it was your work and not mine:

http://svn.rockbox.org/viewvc.cgi?view=rev;revision=19946

saratoga - do you think the (potential) problem with the first file (that looks like an asf parsing issue) is the same as  FS#10027  ?

I’m not sure. I don’t actually know anything about the ASF parser (linuxstb wrote it). I suppose if you’re interested in finding out you could use MS‘s “asf view” and compare the rockbox parser output to MS‘s tool. Sitting down with it and learning how ASF works has been on my todo list for ages but not very near the top.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing