Report source type in item navigation#1079
Conversation
|
Build failed! Build osara pr1079-1423,38ddca8e failed (commit 38ddca8edd by @day-garwood) |
|
I'm not sure why AppVeyor choked on this. Presumably it built fine locally as you've already been testing it @day-garwood? |
|
How embarrassing. Sorry about that... |
When navigating through items, the source type (audio, video, midi) is announced when reporting take information (see issue jcsteh#1066).
|
Build succeeded! Build osara pr1079-1424,ccb10e18 completed (commit ccb10e18c0 by @day-garwood) |
|
Glad you figured it out, apparently I still need more practice reading the AppVeyor output at this end. From here it looked like it went build... building... almost built... BONK! |
|
M4A reports as video at the moment. Is that an easy one to resolve? Haven't looked at the code yet. |
|
Surprised that M4A reports video. Maybe that's because that's usually the audio format used in MP4 videos? Either way it seems that's what the source type is reporting. The code simply checks if the source type reports video or MIDI and returns that, or returns audio for everything else. Does ogg return audio even when it contains video data? Guessing we'll either have to expand my getReportableSourceType function or else find another way of determining the type if it does end up being released. |
|
My guess is that REAPER doesn't have an audio codec for AAC audio, so it uses the video codec instead, which does support it. I'll wager that this also looks like a video item to sighted users, aside from the fact that it doesn't display any actual video of course. IMO, providing more info here than sighted users see is out of scope in this case. |
Can get that confirmed tomorrow. |
jcsteh
force-pushed
the
master
branch
14 times, most recently
from
4e249e9 to
ab43984
Compare
|
Just came across this again while looking through all my open PRs. Is this waiting for action my end? |
|
Oops, looks like it was waiting on verification of which source types are distinguishable visually. I said I'd get that looked at over a year ago. Will try to do it today. |
|
Eventually got eyes on this. Sighted folks show the video window, which populates if they select a video item. Without that window shown though, there's no visual indication that an item contains video. Items containing audio show a waveform and items containing MIDI show a piano roll. So, I guess we only need to report those two types. |
|
If sighted folks can distinguish video when the video window is present, it seems reasonable for us to report this, since that would be much harder for a screen reader user to discern with the video window I think? |
|
Ooh good point. |
4 participants
When navigating through items, the source type (audio, video, midi) is announced when reporting take information (see issue #1066).
In short, "AUDIO" is reported by default for anything that isn't tagged as "VIDEO" or "MIDI". Basic tests show this to be working nicely:
Wav, MP3 and FLAC files report "AUDIO", as do frozen MIDI items which seem to have additional content announced naturally to suggest that it is a frozen MIDI item.
Giff files specify "VIDEO".
MIDI reports MIDI, as expected.
The one thing I haven't tested are container files like MP4 or ogg, or other video formats that inherently support embedded audio (simply because I have none to test with).
Hopefully I've nailed the formatting for this one.