Support and General Use > Audio Playback, Database and Playlists
Codec Efficiency Comparison Test (iPod)
Davide-NYC:
You're correct. Better to slightly expand the Audio Thread screen.
If the audio thread screen told you the current filetype and bitrate as well as time remaining in the current track we'd be set.
;D
Llorean:
Why is all that information important to a codec efficiency test? I would assume that if you were testing it, you'd prepare a playlist containing only the desired filetype and bitrate in advance. As for time remaining in current track, I'm not so sure I see that as useful at all for this.
I'm just saying, I'm not sure any coding actually needs to be done at all, though I could easily be missing where the information would be valuable on that screen.
Davide-NYC:
Maybe I am misunderstanding something or there is a bug in the "View Audio Thread" screen which is causing confusion...
--> What exactly does the "track count" tell us? It is not reporting what I expect it to.
As far as reporting some file info in the View Audio Thread screen:
It would reduce human error and be much easier of the filename, the filetype and the bitrate where displayed on the View Audio Thread screen. If multiple samplerates are implemented then we should display that too (if at all possible)
Since Senab has disabled the "bufferbars" anyway which requires a patching debug_menu.c I'm figuring it's no different to the tester if we add a line on screen that reports file info.
In fact, I vote that if this change gets implemented it should be commited to CVS. It's just useful IMO.
Davide-NYC:
Line 350 of apps/debug_menu.c insert -->
struct mp3entry* id3;
id3 = audio_current_track();
snprintf(buf, sizeof(buf), "filename:");
lcd_puts(0, line++, buf);
snprintf(buf, sizeof(buf), "%s", id3->path);
lcd_puts(0, line++, buf);
snprintf(buf, sizeof(buf), "codectype: %d", id3->codectype);
lcd_puts(0, line++, buf);
snprintf(buf, sizeof(buf), "bitrate: %d", id3->bitrate);
lcd_puts(0, line++, buf);
Llorean:
I'm still not sure why that's at all relevant to a codec efficiency test. All it does it inflate the binary a wee bit more with information already available in plenty of places, and in fact, information that the tester *should* have decided on before starting the test.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version