not freeze upon ogg playback

[Arioch]

I know, this forum is not for feature requests, but for feature ideas.
Yet it is the most likely thing on rockbox.org

Perhaps it is again wrong place, but then could someone give me a link, where to put Feature Request, that rockbox would not require reboot after attempt at hearing ogg/vorbis file ?

[Chronon]

Please use a more descriptive title and describe your idea in more detail.  I accidentally moved it to the Audio Playback forum before realizing what you were asking about.

Here's the text from the closed flyspray entry:

Some containers, like Matroska MKA or like Ogg can contain numerous audio tracks, for example the whole AudioCD contained within single Ogg file.

For example VideoLAN.org plays such files ok, while fails to show separate tracks/tags in playlist.

However, RockBox justs freezes and until reboot can no longer play music (each file is detected as having zero duration)

[saratoga]

I don't think supporting chained ogg files is feasible, but hopefully we can make rockbox not crash on such files.

[linuxstb]

I've reopened your bug report, but changed the subject line to emphasise that it's a bug report, rather than a feature request:

http://www.rockbox.org/tracker/task/9502

As I said there, Rockbox should in theory detect and reject such files, but maybe that's not working as expected.

[bluebrother]

Perhaps it is again wrong place, but then could someone give me a link, where to put Feature Request, that rockbox would not require reboot after attempt at hearing ogg/vorbis file ?

Most of my music is ogg and it doesn't require a reboot after playing a vorbis file ... so as others have said, your report is really confusing as it doesn't tell anything about the issue itself.

[Arioch]

example of files was given, so you may check the difference beween yours and that one

Also i guess you do not have Ogg's encoded with eary versions of ibvorbis, so-called fllor-0 files. They are not played as well.

BTW, what is so bad about chained ogg, that there is no way for RockBox to play them ?

As a sidenote - those filesin PC players:
 AIMP (Win32 player, based upon un4seen BASS lib) plays 1st rack, then skips to next fie
 VideoLAN plays through, but fails in placelist and tags render and artialy fail in navigation within file

[bluebrother]

example of files was given, so you may check the difference beween yours and that one

I think you missed my point.

You claimed ogg files breaking playback. This simply is wrong as it only tells half of the truth: there are two specific, rather rare types of ogg files around that don't play: floor0-files and chained files. I find it rather tentive having to look up a flyspray task to figure what's the exact issue. To address a problem the most important first step is to name the problem as exact as possible. Just requesting to "not freeze upon ogg playback" is not really helpful: it does confuse users, developers and mods in the forums as it's way too unspecific.

The real issue has been named later by others. If you'd done that in the first place yourself your original task most likely wouldn't have been closed (Rockbox shouldn't crash on files it doesn't support, so this qualifies it as bug). Asking for support of chained files is a different issue and could've been done here, but this would have needed to include the correct issue -- as said, supporting chained files.

And that "example was given" ..., well, you're aware that this is distributing copyrighted material? Give an example you actually can distribute.

[saratoga]

BTW, what is so bad about chained ogg, that there is no way for RockBox to play them ?

Its a dumb idea since theres no way to know how many tracks are in a file without playing back the file.  Since we don't necessarily have the entire file loaded from disk at playtime, we can't know how many tracks there are until the decoder suddenly stumbles onto the next track. 

Also, I think we do support floor 0 files.  Theres a decoder built in for them.  I was also going to suggest removing the code for it to reduce memory usage since floor0 files are so rare.

[soap]

There appear to be two issues here, chained and floor-0
Over a year ago Arioch was the impetus for the other, related, task:
http://www.rockbox.org/tracker/task/5796
which suggests that we don't have support for floor-0?

[saratoga]

which suggests that we don't have support for floor-0?

I can't check the .map file since I don't have a linux machine handy, but Tremor's SOURCES file contains this:

bitwise.c
block.c
codebook.c
floor0.c
floor1.c
framing.c

And floor0.c allocates some IRAM variables, suggesting that it at least worked well enough at one point for some to optimize it. 

[linuxstb]

As far as I know, Rockbox supports floor0 vorbis files, but the problem with them is that they need a lot of memory to decode.  This should have improved with a recent commit (which in effect gives more working memory to codecs) - are you running a current version of Rockbox (one later than r18834) ?

The explanation why it's not reasonable for Rockbox to support chained ogg files is simply because Ogg is a badly designed format (for resource-restricted devices).  (This is all just my understanding - and a description of what Rockbox currently does - if it's wrong, I would be very happy to be corrected).

The header of an Ogg file doesn't include the total length of the file.  In order to calculate this length, Rockbox has to seek to the end of the file, and work backwards to find the start of the last "page" in the file.  It then reads the "granule position" of that last page, and uses that to calculate the length of the file.

If that wasn't bad enough, chained ogg files are simply standard Ogg files concatentated together.  There is no extra information at the start of the file to indicate that this file contains multiple Ogg files.  So in order for any player to show you the information on the individual tracks, it needs to read the entire file and walk through it from start to end, to find individual tracks.

Ogg files should contain a unique "serial number" in the page headers, and Rockbox contains code which compares the serial number of the first page in a file with the serial number of the last page.  If these numbers are different, then it assumes it's a chained ogg file, and (should) reject it.

Which I think may be your problem - I remember Rockbox just going into an infinite loop when presented with a playlist where every file is rejected.  Try putting a valid file (e.g. an mp3) in the same directory and see if Rockbox plays that.

[Lear]

For chained files, the lack of a real malloc in the Rockbox codec is probably the biggest problem right now. When switching to a new stream, it needs to free the Vorbis (or codec) allocations, but not the Ogg (container/file buffering) allocations. Changing the Ogg code to only use static buffers would work too.

Detecting (valid) chained files, and determine where each part starts (which is needed for seeking to work) does require a bit of searching/reading in the file, which can take a little while (and needs to be done by the metadata code), but it typically doesn't need to read the entire file to do this.