The meeting covered two different subjects. The first was how to compare generated speech responses. The second was what happens when the Omni task is missing, unavailable, or technically broken.

These subjects are related, but they should not be confused. A contributor can understand the evaluation criteria and still have no tasks available. Similarly, a contributor may see a task in the dashboard but be unable to complete it because the audio or rating controls fail to load.

Outlier is a platform where contributors may be assigned tasks to help evaluate or improve AI systems. In this webinar, the specific task family was Omni TTS ELO.

TTS stands for text-to-speech. In this context, the system generates speech from text, and the contributor compares two generated responses. ELO refers here to the pairwise comparison workflow described in the meeting. The supplied transcript does not establish the complete internal scoring mechanism, so I am not assuming how the platform calculates its underlying scores.

The most important thing I took from this distinction is that Omni TTS ELO is not simply a question of choosing the voice I personally like. I have to judge the responses against the task's criteria.

1. Read the instructions and transcript.

   Understand what should be spoken and whether the task requests a particular tone, emotion, or speaking style. Some local-language tasks may have no additional instruction beyond the transcript.

2. Listen to the reference voice, if provided.

   Notice stable characteristics such as pitch, timbre, vocal texture, accent, and speaking patterns. These observations will help when judging personal likeness.

3. Listen to Response A completely.

   Follow the transcript while listening. Look for missing words, added speech, mispronunciation, unnatural pauses, background noise, and distortion.

4. Listen to Response B completely.

   Apply the same checks independently. If necessary, replay the relevant parts rather than relying on memory of the first response.

5. Rate each dimension separately.

   Recording quality, speaker similarity, pronunciation faithfulness, and naturalness measure different things. One weakness should not automatically determine every other rating.

6. Choose the overall winner.

   Compare the responses holistically and select A or B when the task requires a winner. The webinar described no tie option for this decision.

7. Identify the dominant factor.

   Select the dimension that most strongly explains why the chosen response won. It should agree with the ratings already made.

8. Review the form before submitting.

   Confirm that every required field is complete and that both audio samples loaded properly. If the sample is unusable, follow the current rejection instructions.

During the webinar, the presenter repeatedly stressed the importance of judging each dimension independently. A response can be excellent in one respect and weaker in another. The objective is to identify those differences rather than letting one impression dominate the entire task.

The distinction that matters most

Imagine that both samples contain the correct words and there is a reference voice. The task is to compare the following responses.

I would not automatically declare A the winner simply because it has cleaner audio. Nor would I automatically choose B because it sounds more expressive. I would evaluate every dimension first.

Overall preference

Once the individual dimensions are rated, the contributor must select the overall winner. The presenter described this as a holistic decision rather than simply copying whichever response won one individual dimension.

For example, Response A might be cleaner and more faithful, while Response B has slightly more natural delivery. The overall choice should reflect the complete comparison and the current task instructions.

Dominant factor

The dominant factor is the dimension that most strongly explain the overall preference. It should be a dimension in which the selected response actually performed better, rather than one rated as a tie.

My practical check would be to ask: if I selected A overall, can I explain that decision using the ratings I just assigned? If not, I would review the comparison before submitting.

The presenter described a new-comparison option for situations where a contributor cannot confidently evaluate a sample or encounters a problematic task. The precise controls and eligibility rules should always be checked in the active interface.

A substantial part of the meeting focused on contributors who could not access Omni or who saw a task appear in the queue and then disappear. Others said that a task opened but failed during loading.

The project representative explained that task availability could be limited, tasks might be claimed quickly, and project assignment was not necessarily something the QM could change manually. The representative also acknowledged reports of a loading issue, although they could not confirm whether it had already been resolved.

What the meeting did not establish

• It did not establish that every missing task is caused by an empty queue.
• It did not establish that every loading error has been fixed.
• It did not establish that a QM can restore a contributor's project assignment.
• It did not establish that an empty queue means a contributor has failed quality review.
• It did not provide a guaranteed workaround for every technical problem.

A safe diagnostic sequence

1. Read the exact status message.

   "No tasks available", "audio failed to load", and "not eligible" describe different situations.

2. Check official project updates.

   Look for a current incident post, loading-issue announcement, or support instruction.

3. Retry once carefully.

   A single refresh or a fresh supported browser session may help with some local interface problems. This is a general diagnostic step, not a confirmed fix for the reported Outlier issue.

4. Check basic local conditions.

   Confirm that the internet connection is stable, the browser is supported and up to date, and audio playback is not muted or blocked.

5. Record the evidence.

   Note the local date and time, time zone, exact error, whether the audio started playing, and which action caused the problem.

6. Report through the approved support channel.

   Provide only the information requested by support. Redact personal information from any screenshot.

Example support message

I also collected public Reddit discussions relating to Aether, Omni TTS ELO, task availability, loading errors, and onboarding. These discussions are useful because contributors describe the situations they encounter in practice. They are not official policy, and an individual report cannot establish the cause of another person's problem.

What I could not verify

My research did not identify a GitHub repository that I could confidently treat as an authoritative source for this specific Omni TTS ELO workflow. A repository using the word "Aether" may belong to an unrelated project.

That does not prove no relevant repository exists. It simply means I could not verify one as a dependable task-specific reference in the research collected for these notes.

The biggest lesson for me is that audio evaluation requires separating different kinds of evidence. A clean recording is not necessarily natural, a natural voice is not necessarily faithful to the transcript, and a similar voice is not necessarily the most accurate one.

The Q&A also made an important practical distinction: understanding the task does not guarantee that tasks will be available at every moment. Contributors may encounter queue shortages, assignment differences, or interface problems. Those situations need to be investigated separately instead of assuming the worst from a missing task tile.

I created this guide because I wanted the useful parts of the webinar to be accessible in one place. As I collect more meeting notes and public resources, I intend to expand the repository with additional preparation material, troubleshooting examples, and project-specific guides.