View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004291 | MMW v4 | Player | public | 2008-01-15 17:53 | 2008-01-23 23:55 |
| Reporter | jiri | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0004291: f_aac_codec: Time and seek problems | ||||
| Description | A user sent me a sample track that doesn't play in f_aac, even though it plays well in other players. We can't do much about it, since the problem seems to be in QT (some AVs there). However, the file also exhibits some problems in our f_aac_codec plug-in: 1. When only f_aac_codec plug-in is enabled (and f_acc isn't) MM shows incorrect track length (0:41 is the correct one). It isn't a big issue, since f_aac is expected to be always present at least for tagging purposed. That said, it might be an indication of some problems. 2. Seeking is somehow weird, after seeking forward, seeking back doesn't work, sometimes track finishes too early etc. I tried to play the track in my WinAmp and it didn't play there, so I don't know how much it is corrupted, or what's wrong. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Assigning to Ludek to review. |
|
|
The track on the FTP plays fine by using f_aac for me. Which version of QT you have? I have QT 7.2. Re: 1. When f_aac_codec plug-in is enabled MM shows the incorrect track length (1:22 instead of 0:44) only in for the attached (according you corrupted) track. For any others tracks it works fine in my case. Re: 2. Seeking is somehow weird: This doesn't seem to be related to f_aac_codec, because I noticed this also in case of f_aac playback. It seems to be rather related to the output plugin, if I changed from 'out_MMDS.dll' to 'out_wave.dll' the problem gone away. |
|
|
1. Ok, but since both plug-ins use our code for getting track length (i.e. it doesn't depend on QT in f_aac) we should rather check out why there is that difference. 2. There really seems to be something wrong with f_aac_codec, seeking even causes AVs sometimes! For debugging purposes I added: OutputDebugString( pchar( string( formatplus( 'Decode: %x, %d, %d', [integer(Position), ReadBytes, Result])))); after Result := FormatHandler.F_DecodeChunk( Decoder, Position, ReadBytes); in FormatsHandler.pas. After some seeking the returned Position values are even outside of the dll (and process) address space, which apparently causes AV just a little later. |
|
|
I most probably found the root of the problem: The file attached on our FTP seems to be an '.alac' file renamed to '.m4a' therefore there are the seeking problems, because seeking for ALAC has not been implemented yet. This explains both 1. and 2., for uncorrupted m4a files seeking works fine and track length is also reported correctly. |
|
|
Ok, but it doesn't really explaing 1 nor 2. Note that ALAC stored in m4a container isn't anything non-standard, it's pretty much how many (or most?) ALACs are distributed. |
|
|
Seeking for ALAC added and both 1 and 2 fixed. The new installing packages uploaded. |
