Earlier this year, I published an industry report called Remediation at Scale analyzing how application security (AppSec) teams fix vulnerabilities in their code. The dataset: tens of thousands of repositories, a full year of scan data, and organizations ranging from startups to enterprises. In total, north of 127 million data points spanning individual findings, scan events, and remediation actions across two types of security scanning (SAST and SCA).

I’m a Senior Technical PMM at Semgrep with a background in computer science, data science, and solutions engineering. I like building things. This project let me combine all of that in a single motion: writing the SQL, building scripts to manage the analysis, parsing and cleaning the data, finding the story the data is telling, and shipping the final polished asset.

This post walks through five lessons I picked up along the way. If you’ve ever had to take a massive dataset, find the narrative inside it, and turn it into something a technical and non-technical audience can act on, some of this might be useful.

1. Start with the data, not the story

The temptation with any data project is to decide your narrative first, then go looking for numbers to back it up. I did the opposite.

I spent weeks in pure exploration mode. Querying Snowflake, looking at distributions, running aggregations across different dimensions. No hypothesis, no angle. Just trying to understand what the data actually showed.

This was uncomfortable. Stakeholders wanted to know what the report would say. I didn’t have an answer yet.

But it turned out to be the most important phase of the entire project. The data told a story I wouldn’t have guessed: the gap between top-performing security teams and everyone else wasn’t about tooling. It was about systematic follow-through on remediation. I never would have landed on that framing if I’d started with a thesis.

You also have to be willing to kill your darlings. There were several findings I wanted to be true that the data didn’t support. On the flip side, some of the most interesting insights came from places I wasn’t looking. I used local LLMs via Ollama to classify 10,000+ text-based triage records into 20 thematic categories. What emerged was a clear pattern: the most common themes were about test files, framework protections, and trusted services. That told a story about how teams actually use triage tooling that I never would have found by looking at aggregate metrics.

A few things that helped during exploration:

• Run diagnostic queries first. I built a set of 12+ data quality checks before touching the analysis. One of them caught that a key metric (parse_rate) only had coverage for a fraction of repos. I switched to an alternative field (NUM_BYTES_SCANNED) with 90%+ coverage. Without that diagnostic, the entire findings-per-lines-of-code analysis would have been mis-computed.
• Build checkpoint/resume into your pipeline. I had 108+ SQL queries across multiple report sections. I wrote a shell script that auto-discovered .sql files, tracked which ones had already produced output CSVs, and skipped them on re-runs. When queries failed midway through (and they did), I could pick up right where I left off instead of re-running everything.
• Document as you go. Every interesting result, every dead end, every assumption. That running log became the backbone of the report’s methodology section and saved me weeks when I needed to retrace my steps.

2. Become the domain expert

You can’t tell a story about data you don’t understand. Before I could write a single section, I needed to know how static analysis scanners work, how remediation flows operate in practice, and what metrics actually matter to security teams.

Several companies in the space publish annual reports on similar topics. I collected and read as many as I could find. Not to copy, but to understand the format, the depth, and the expectations. Reading them gave me a sense of:

• What the industry expects from this kind of resource
• What’s already well-covered
• Where there’s room to say something new

This also helped me spot gaps. Most reports focus on detection volume. Very few dig into what happens after detection. That became our angle.

Skipping this phase would have meant writing a report full of surface-level observations that didn’t differentiate against the other great content produced by others.

3. Talk to your target audience early and often

Early versions of the analysis just showed averages. Average fix rate, average time to remediate, average findings per repo. The numbers were fine. The story was boring.

The breakthrough came after talking to actual practitioners: the security engineers, AppSec leads, and CISOs who would be reading the final product. Everyone wanted to answer one question: how do I compare to teams that are doing this well?

That feedback directly shaped two of the biggest decisions in the report.

First, it led to a cohort-based segmentation. I split organizations into two groups: the top 15% by fix rate (“leaders”) and everyone else (“the field”). This is similar to how survey-based reports segment by maturity level, except I was using behavioral data rather than self-reported responses. Suddenly the data had contrast:

• Leaders fix 2–3x more vulnerabilities
• They resolve findings caught during code review 9x faster than findings from full repository scans
• They adopt workflow automation features at higher rates and extract more value from them

The segmentation was the difference between “here are some numbers” and “here is something you can act on.”

Second, it reshaped the report’s structure. People didn’t just want benchmarks. They wanted to know what to do about them. “Great, the leader cohort fixes more code security vulnerabilities. How do I become a leader?” That feedback led me to add an evidence-based recommendations section organized by implementation speed:

• Quick wins for this week
• Process changes for this quarter
• Strategic investments for the half

The final report reads as much like a playbook as it does a benchmark. None of that would have happened without putting early drafts in front of actual readers.

4. Get design involved early

This one I almost learned too late. Data reports live or die on how they look. A wall of charts with no visual hierarchy is just as bad as no data at all.

I brought in our design team earlier than I normally would and spent time walking them through the domain. What does “reachability analysis” mean? Why does the cohort split matter? When the designers understood the story, they made choices (color coding for cohorts, callout boxes for key insights, before/after code examples) that reinforced it without me having to explain in text.

5. Give yourself time

This project took months. The data exploration alone was weeks. Then there were iterations on the analysis as I found new angles, design cycles, legal reviews, and rounds of feedback from stakeholders across the company.

If I had tried to ship this in a quarter, the result would have been forgettable.

Where it landed

Looking back, the two things I’d change are both about speed. I’d write down every definition and assumption on day one. Things like “what counts as an active repository” or “how do we calculate fix rate” seem obvious at the start. They become contested fast. I eventually created a formal definitions document covering 40+ metrics, but doing it earlier would have saved several rounds of rework. And I’d bring in a second set of eyes during exploration. Working solo meant no one to gut-check whether a finding was interesting or just noise.

The report itself, Remediation at Scale, covers six evidence-backed patterns that separate high-performing security teams from the rest. If you’ve tackled a similar data-heavy reporting project, I’d be curious to hear what you learned along the way.

Recently, while exploring syndicating Dolby.io WebRTC streams, I learned that Twitch has added support for WebRTC Ingest or WHIP as it is known in the industry.

WebRTC for streaming is an exciting choice because it can decrease stream latency compared to traditional protocols such as RTMP and HLS. When ingested, Twitch will transmux the WebRTC stream into something the platform supports (HLS), so that adds latency, slowing down the feed.

With that said, WHIP support is a great step for the community and with OBS now adding support for WebRTC, I thought I’d have to try it out.

In this guide, we’ll showcase how to stream WebRTC from OBS into Twitch.

Setting up OBS for WebRTC

The core OBS project has recently added WebRTC support (with WHIP)! You can download the OBS project here.

Once downloaded, extract the project and install it.

Streaming WebRTC from OBS to Twitch

With the project installed and launched, navigate to:
Settings -> Stream

Inside of Stream select WHIP as your service:

To start a WebRTC stream to Twitch you need the Server path and your Stream key.

The Twitch WHIP server

The server is (currently) the same for everyone:
https://g.webrtc.live-video.net:4443/v2/offer

Note: This server currently only supports H264 and Opus-encoded streams.

Getting Your Twitch Stream Key

Your Twitch Stream Key can be found on your dashboard once you’ve logged in, under:
settings -> stream

Copy both the Server URL and the Stream Key into the Server and Bearer Token inputs within OBS.

Click Apply, set up OBS as usual, and click Start Stream to begin your WebRTC broadcast to Twitch.

Learn More

Broadcasting a WebRTC stream to Twitch is a great feature for the site as it allows people to easily syndicate their WebRTC streams to a popular platform. Because Twitch transmuxes the WebRTC stream, some delay is added, so if you’re looking for an end-to-end white-label real-time streaming solution, check out Dolby.io Real-time Streaming.

A special shout out to Sean DuBois for his work on both the OBS project and Twitch’s WHIP support.

Social gaming has exploded in popularity thanks to leaps in technology and innovation in the communication and gaming space. For GDC 2023, Dolby.io and PubNub discussed the social gaming landscape and how both companies are powering innovations in immersive communication.

To learn more about Dolby.io and PubNub, join Developer Advocates Braden Riggs (Dolby.io) and Oliver Carson (PubNub) as they dive into the world of social gaming in their talk:
No Headset, No Problem: Building Social Gaming Experiences for Every Device

If you are interested in trying out the demo app from the talk head over to the project on GitHub or learn more about the Dolby.io Spatial Audio and Streaming Plugins for Unity and Unreal. For building social experiences on the Web check out this guide showing how to build a WebRTC streaming app with PubNub and Dolby.io.

No Headset, No Problem: Building Social Gaming Experiences for Every Device was originally published in Hacking Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

Streaming, especially the low latency kind, has become a popular medium to engage with an audience, host live events, and connect people virtually. For developers building streaming apps, however, there is just one issue. If we are interested in connecting to a wide audience we need to develop for a wide range of platforms such as Android, iOS, Web, and even desktop native apps, which can quickly become a heavy lift for any team. This is where Flutter 3 comes in, released in May of 2022, Flutter 3 takes cross-platform to the next level allowing users to “ build for any screen” from a single code base. Hence, rather than building 3 separate apps for iOS, Android, and Web, you can build just one. To further sweeten the deal, Dolby.io has recently released their WebRTC real-time streaming SDK for Flutter, allowing users to build cross-platform streaming apps that combine scalability and ultra-low delay.

In this guide, we’ll be exploring how to build a cross-platform real-time streaming app that works on Android, iOS, Desktop Native, and Web using the Dolby.io Streaming SDK for Flutter.

Getting Started with the Real-Time Streaming SDK

Before we begin you need to make sure you have the latest version of Flutter installed and set up on your machine. To get started with building a streaming app we need to install the Dolby.io Streaming SDK for Flutter 3 via the terminal.

flutter pub add millicast_flutter_sdk

Then run the following command in terminal to download the dependencies:

flutter pub get

With the Flutter Streaming SDK installed, you can start by creating a vanilla Flutter app and add the most recent version of flutter_webrtc to your project's pubspec.yaml. You should also see that the Dolby.io Millicast flutter SDK has been automatically added.

flutter_webrtc: ^x.x.x millicast_flutter_sdk: ^x.x.x

Then inside main.dart you just import flutter_webrtc alongside any other dependencies your project may have.

import 'package:flutter_webrtc/flutter_webrtc.dart';

In addition to installing the SDK, you’ll also need to create a free Dolby.io Account. The free account offers 50 Gigabytes of data transfer a month, which will be plenty for building and testing out the real-time streaming app.

Interested in following along with a project that already has the SDK installed and set up? Check out this GitHub repository which contains a completed version of this app.

Building the Real-Time Streaming App with Flutter

Building a WebRTC Flutter streaming app can be complicated, so to get started we first need to divide the app into a series of features that come together to support a real-time streaming experience. In order for the app to connect to the Dolby.io servers, we must include a way for the user to input their streaming credentials and tokens in order to authenticate and use the Dolby.io servers.

Taking in the WebRTC Stream Credentials

To publish and view a WebRTC stream with the Dolby.io Flutter SDK we need three things: an account ID, a stream name, and a publishing token. These credentials can be found on your Dolby.io dashboard and need to be input by the user which we can capture with the TextFormField widget, where the widget, on change, updates a TextEditingController variable.

Container(
                            width:MediaQuery.of(context).size.width,
                              constraints: const BoxConstraints(
                                  minWidth: 100, maxWidth: 400),
                              child: TextFormField(
                                maxLength: 20,
                                controller: accID,
                                decoration: const InputDecoration(
                                  labelText: 'Enter Account ID',
                                ),
                                onChanged: (v) => accID.text = v,
                              )),

Note: In production, you don’t need to have users input these credentials, instead you could use a custom login and serve the users a temporary login token. For learning more about Dolby.io tokens check out this blog on creating and securing tokens.

Because we need three inputs to publish a WebRTC stream to the Dolby.io server, we can repeat this code for each input.

Container(
                              width:MediaQuery.of(context).size.width,
                              constraints: const BoxConstraints(
                                  minWidth: 100, maxWidth: 400),
                              child: TextFormField(
                                maxLength: 20,
                                controller: streamName,
                              onChanged: (v) => streamName.text = v,
                                decoration: const InputDecoration(
                                  labelText: 'Enter Stream Name',
                                ),
                              )),
                          Container(
                              width:MediaQuery.of(context).size.width,
                              constraints: const BoxConstraints(
                                  minWidth: 100, maxWidth: 400),
                              child: TextFormField(
                                controller: pubTok,
                                maxLength: 100,
                                onChanged: (v) => pubTok.text = v,
                                decoration: const InputDecoration(
                                labelText: 'Enter Publishing Token',
                                ),
                              )),

Additionally, we can add an ElevatedButton for the user to press once they have added their credentials.

ElevatedButton(
               style: ElevatedButton.styleFrom(
                              primary: Colors.deepPurple,
                            ),
                            onPressed: publishExample,
                            child: const Text('Start Stream'),
                          ),

Authentication and Publishing Streams from Flutter

You’ll notice that the Elevated button triggers a function via its onPressed parameter. This function, called publishExample, checks if the credentials are valid and authenticates the stream. First, the function checks that a user has input a value for each input.

void publishExample() async {
    if (pubTok.text.isEmpty || streamName.text.isEmpty || accID.text.isEmpty) {
      ScaffoldMessenger.of(context).showSnackBar(const SnackBar(
        backgroundColor: Colors.grey,
        content: Text(
            'Make sure Account ID, Stream Name, and Publishing Token all include values.'),
      ));
    }

Then the function calls publishConnect, an asynchronous function that takes in streamName, pubTok, and a third object called localRenderer. localRendered is a RTCVideoRenderer object included with the flutter.webrtc package.

final RTCVideoRenderer localRenderer = RTCVideoRenderer(); 
publish = await publishConnect(localRenderer, streamName.text, pubTok.text);

Using these three parameters we have everything we need to authenticate and begin publishing a stream. Inside of the publishConnect function, we need to generate a temporary publishing token using the streamName and pubTok:

Future publishConnect(RTCVideoRenderer localRenderer, String streamName, String pubTok) async { 

// Setting subscriber options 
DirectorPublisherOptions directorPublisherOptions =    DirectorPublisherOptions(token: pubTok, streamName: streamName); 

/// Define callback for generate new token tokenGenerator() => Director.getPublisher(directorPublisherOptions); 
... }

With the temporary publishing token created, we then can use it to create a publish object. Using this publish object we could start the stream, however, we wouldn't be able to see or hear anything, this is because we haven't specified what kind of stream we are creating or which devices we will connect to. To do this we need to specify if the stream will include audio, video, or audio and video, then we need to pass these constraints into the getUserMedia function which will map the constraints to the default audio capture device and the default video capture device.

{ ... 
Publish publish = Publish(streamName: 'your-streamname', tokenGenerator: tokenGenerator); 
final Map<String, dynamic> constraints = <String, bool>{ 
'audio': true, 
'video': true 
}; 
MediaStream stream = await navigator.mediaDevices.getUserMedia(constraints); ... }

Using this stream object, we can also provide a feed to the user in the form of a viewer. To do this we need to assign our input devices to localRender as sources.

{ ... 
localRenderer.srcObject = stream; 
... }

Finally, we can map the stream object and pass it as an option to the connect function, which is inherited from publish.

{ ... 
//Publishing Options 
Map<String, dynamic> broadcastOptions = {'mediaStream': stream}; 

/// Start connection to publisher 
await publish.connect(options: broadcastOptions); 
return publish; }

With our stream connected, we can now look at setting up the viewer using localRender.

In-App WebRTC Stream Viewer

Now that our stream is authenticated and publishing we need to add a viewer object so the streamer can see themselves streaming. This can be done with a RTCVideoView object which takes in our localRender object and is constrained by a container.

Container(
                margin: const EdgeInsets.all(30),
                constraints: const BoxConstraints(
                   minWidth: 100, maxWidth: 1000, maxHeight: 500),
                width: MediaQuery.of(context).size.width,
                height: MediaQuery.of(context).size.height / 1.7,
                    decoration:
                       const BoxDecoration(color:Colors.black54),
                    child: RTCVideoView(_localRenderer, mirror: true),
                          )

Sharing the Real-time Stream

With the stream authenticated and live, we want to share our content with the world. We can do this via a URL formatted with our streamName and our accountID which we collected as inputs. Using the example app as a template we can create a function called shareStream which formats the URL to share and copies it to the clipboard.

void shareStream() {
    Clipboard.setData(ClipboardData(
        text:
            "https://viewer.millicast.com/?streamId=${accID.text}/${streamName.text}"));
    ScaffoldMessenger.of(context).showSnackBar(const SnackBar(
      backgroundColor: Colors.grey,
      content: Text('Stream link copied to clipboard.'),
    ));
  }

Unpublishing a WebRTC Stream

To unpublish the stream we can call the publish object returned from our asynchronous publishConnect function to stop, killing the connection with the Dolby.io server.

publish.stop();

Flutter 3 is Truly Cross Platform

The power of Flutter is taking one code base and having it work across multiple platforms. Here we can see examples of the app working for Android, Windows, and Web:

Building in this cross-platform framework saves both time and resources, allowing you to get started building real-time streaming apps without having to worry about which platform works for your users. These apps are perfect for streaming live events and virtual events to the widest range of audiences allowing for high-quality interactive experiences. If you are interested in learning more about our Flutter streaming SDK check out our documentation and play around with the full project on this GitHub repository.

Feedback or Questions? Leave a Medium Comment or reach out to me on Twitter.

Originally published at https://dolby.io on September 30, 2022.

For anyone who hasn’t already heard PyScript, which debuted at PyCon 2022, is a browser-embedded python environment, built on top of an existing project called Pyodide. This project, to the shock of long-term Pythonistas and web developers, seamlessly blends (well almost) JavaScript and Python in a bi-directional environment allowing developers to utilize Python staples such as NumPy or Pandas in the browser.

After playing with the project for a few days I wanted to share a few learnings and gotchya’s that tripped me up on my journey to master PyScript.

Prelude: A Crash Course in PyScript
1. Package Indentation Matters!
2. Local File Access
3. DOM Manipulation

A Crash Course in PyScript

To get started using PyScript we first have to link our HTML file with the PyScript script as we would for any ordinary javascript file. Additionally, we can link the PyScript style sheet to improve usability.

<head>
    <link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />
    <script defer src="https://pyscript.net/alpha/pyscript.js"></script>
</head>

With PyScript imported in the head of our HTML file, we can now utilize the <py-script> tag in the body of our HTML to write python code.

<body>
    <py-script>
        for i in ["Python", "in", "html?"]:
            print(i)
    </py-script>
</body>

Yep! It really is just that simple to get started. Now, where do things get tricky?

Package Indentation Matters

One of the big advantages of using PyScript is the ability to import Python libraries such as NumPy or Pandas, which is first done in the Head using the <py-env> tag and then inside of the <py-script> tag just like you would in regular Python.

<head>
    <link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />
    <script defer src="https://pyscript.net/alpha/pyscript.js"></script>

    <py-env>
- numpy
- pandas
    </py-env>
</head>

<body>
    <py-script>
        import pandas as pd
    </py-script>
</body>

On the surface, this may seem straightforward but note the indentation of the packages within <py-env>.

    <py-env>
- numpy
- pandas
    </py-env>

Turns out that if there is any indentation you’ll receive a ModuleNotFoundError: No module named ‘pandas’ or ModuleNotFoundError: No module named ‘numpy’ ) for PyScript. This error caught me off guard initially since indentation in Python is so important.

Local File Access

JavaScript handles file access very differently compared to Python… as it should given the relationship between web development and privacy and security. Hence Vanilla JavaScript does not have direct access to local files. Since the PyScript project is built on top of JavaScript your Python code won't be able to access local files like you might be used to.

PyScript does offer a solution to file access in the <py-env> tag. In addition to importing packages, you can also import files such as CSVs or XLSXs.

    <py-env>
- numpy
- pandas
- paths:
    - /views.csv
    </py-env>

Again note the indentation as in this case the CSV must be indented in relation to the paths.

With the file included in the path, you can read it within your <py-script> code.

<py-script>
    import pandas as pd
    df = pd.read_csv("views.csv")
</py-script>

DOM Manipulation

For anyone who has worked in web development, you should be familiar with the DOM or Document Object Model. DOM Manipulation is common in most web applications as developers typically want their websites to interact with users, reading inputs and responding to button clicks. In the case of PyScript this raises an interesting question how do buttons and input fields interact with the Python code?

Again PyScript has a solution to this, however, it mightn’t be what you expect. Here are a few (of many) examples where PyScript has functionality:

1. For buttons, you can include pys-onClick=”your_function” parameter to trigger python functions when clicked.
2. For retrieving user input from within the <py-script> tag document.getElementById(‘input_obj_id’).value can retrieve the input value.
3. And Finally pyscript.write(“output_obj_id”, data) can write output to a tag from within the <py-script> tag.

We can see these three DOM manipulation techniques put together into one web application that lets users check if a CSV has been added to the PyScript path:

<body>
   <form onsubmit = 'return false'>
   <label for="fpath">filepath</label>
   <input type="text" id="fpath" name="filepath" placeholder="Your name..">
   <input pys-onClick="onSub" type="submit" id="btn-form" value="submit">
    </form>

<div id="outp"></div>

    <py-script>
        import pandas as pd

        def onSub(*args, **kwargs):
            file_path = document.getElementById('fpath').value
            df = pd.read_csv(file_path)
            pyscript.write("outp",df.head())
    </py-script>
</body>

These examples aren’t comprehensive as the project also supports visual component tags.

Conclusion

PyScript is a wonderful step in the right direction for bringing some excellent Python packages into the web development space. With that said it still has a bit of growing to do and there are many improvements that need to be made before the project sees widespread adoption.

Show some support to the team working on this awesome project: https://github.com/pyscript

Leave a comment with any other insights or gotchya’s that you might have experienced working with PyScript and I’ll make a part 2.

3 Things to Know Before Building with PyScript was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Hacking Media publication aims to bring high-quality content relating to software development and research in the media space, be that video or audio correction software, data generation tools, visualization tools and so forth.

Publishing with Hacking Media

Currently, we are open to article submissions. If your article is in line with Medium’s terms of service and rules you can make a submission here.

You always own and control the rights to your content so feel free to remove or change publications as you please.

Editors and Publishers

Braden Riggs: Braden is a developer advocate with Dolby specializing in data generation and media post-production tools.

Introducing Hacking Media was originally published in Hacking Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since the inception of cinema, Scores, the musical composition within a film, have become synonymous with the medium and a crucial staple in the experience of enjoying film or TV. As the industry has grown and matured so too has the score, with many productions having hundreds of tracks spanning many genres and artists. These artists can be anyone from an orchestra drummer all the way up to a sellout pop star sensation, each composing, producing, or performing a variety of tracks. The challenge with this growing score complexity is ensuring that every artist is paid for their fair share and contribution to the overall film.

The industry presently tackles this challenge with a tool known as a “Cue Sheet“, a spreadsheet that identifies exactly where a track is played and for how long. The issue with Cue Sheets is that their creation and validation is an immensely manual process, constituting hundreds of hours spent confirming that every artist is accounted for and compensations are awarded accordingly. It was this inefficiency that attracted Dolby.io to help support the Cue Sheet Palooza Hackathon, a Toronto-based event that challenged musicians and software engineers to work and innovate together to reduce the time spent creating Cue Sheets. The event was sponsored by the Society of Composers, Authors and Music Publishers of Canada or SOCAN for short, which is an organization that helps ensure Composers, Authors, and Music Publishers are correctly compensated for their work.

Many of the hackers utilized the Dolby.io Analyze Media API to help detect loudness and music within an audio file and timestamp exactly where music is included. In this guide, we will highlight how you can build your own tool for analyzing music content in media, just like the SOCAN hackathon participants.

So what is the Analyze Media API?

Before we explained how hackers used the API we need to explain what Analyze Media is and what it does. The Dolby.io Analyze Media API generates insight based on the underlying signal in audio for creating data such as loudness, content classification, noise, and musical instruments or genre classification. This makes the API useful for detecting in what section music occurs in an audio file and some qualities of the music at that instance.

The Analyze Media API adheres to the Representational state transfer (REST) protocol meaning that it is language-agnostic and can be built into an existing framework that includes tools to interact with a server. This is useful as it means the API can adapt depending on the use case. In the Cue Sheet example many teams wanted to build a web application as that was what was most accessible to the SOCAN community, and hence relied heavily on HTML, CSS, and JavaScript to build out the tool.

In this guide, we will be highlighting how the participants implemented the API and why it proved useful for audio media. If you want to follow along you can sign up for a free Dolby.io account which includes plenty of trial credits for experimenting with the Analyze Media API.

A QuickStart with the Analyze Media API in JavaScript:

There are four steps to using the Analyze Media API on audio:

1. Store the media on the cloud.
2. Start an Analyze Media job.
3. Monitor the status of that job.
4. Retrieve the result of a completed job.

The first step, storing media on the cloud depends on your use case for the Analyze Media API. If your media/audio is already stored on the cloud (Azure AWS, GCP) you can instead move on to step 2. However, if your audio file is stored locally you will first have to upload it to a cloud environment. For this step, we upload the file to the Dolby.io Media Cloud Storage using the local file and our Dolby.io Media API key.

async function uploadFile() {
    //Uploads the file to the Dolby.io server
    let fileType = YOUR_FILE_TYPE;
    let audioFile = YOUR_LOCAL_MEDIA_FILE;
    let mAPIKey = YOUR_DOLBYIO_MEDIA_API_KEY;
 
    let formData = new FormData();
    var xhr = new XMLHttpRequest();
    formData.append(fileType, audioFile);
 
    const options = {
        method: "POST",
        headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
            "x-api-key": mAPIKey,
        },
        // url is where the file will be stored on the Dolby.io servers.
        body: JSON.stringify({ url: "dlb://file_input.".concat(fileType) }),
    };
 
    let resp = await fetch("https://api.dolby.com/media/input", options)
        .then((response) => response.json())
        .catch((err) => console.error(err));
 
    xhr.open("PUT", resp.url, true);
    xhr.setRequestHeader("Content-Type", fileType);
    xhr.onload = () => {
        if (xhr.status === 200) {
            console.log("File Upload Success");
        }
    };
    xhr.onerror = () => {
        console.log("error");
    };
    xhr.send(formData);
    let rs = xhr.readyState;
 
    //Check that the job completes
    while (rs != 4) {
        rs = xhr.readyState;
    }
}

For this file upload, we have chosen to use XMLHttpRequest for handling our client-side file upload, although packages like Axios are available. This was a deliberate choice as in our Web App we add functionality for progress tracking and timeouts during our audio upload.

With our audio file uploaded and stored on the cloud we can start an Analyze Media API job which is done using the location of our cloud-stored media file. If your file is stored on a cloud storage provider such as AWS you can use the pre-signed URL for the file as the input. In this example, we are using the file stored on Dolby.io Media Cloud Storage from step 1.

async function startJob() {
    //Starts an Analyze Media Job on the Dolby.io servers
    let mAPIKey = YOUR_DOLBYIO_MEDIA_API_KEY;
    //fileLocation can either be a pre-signed URL to a cloud storage provider or the URL created in step 1.
    let fileLocation = YOUR_CLOUD_STORED_MEDIA_FILE;
 
    const options = {
        method: "POST",
        headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
            "x-api-key": mAPIKey,
        },
        body: JSON.stringify({
            content: { silence: { threshold: -60, duration: 2 } },
            input: fileLocation,
            output: "dlb://file_output.json", //This is the location we'll grab the result from.
        }),
    };
 
    let resp = await fetch("https://api.dolby.com/media/analyze", options)
        .then((response) => response.json())
        .catch((err) => console.error(err));
    console.log(resp.job_id); //We can use this jobID to check the status of the job
}

When startJob resolves we should see a job_id returned.

{"job_id":"b49955b4-9b64-4d8b-a4c6-2e3550472a33"}

Now that we’ve started an Analyze Media job we need to wait for the job to resolve. Depending on the size of the file the job could take a few minutes to complete and hence requires some kind of progress tracking. We can capture the progress of the job using the JobID created in step 2, along with our Media API key to track the progress of the job.

async function checkJobStatus() {
    //Checks the status of the created job using the jobID
    let mAPIKey = YOUR_DOLBYIO_MEDIA_API_KEY;
    let jobID = ANALYZE_JOB_ID; //This job ID is output in the previous step when a job is created.
 
    const options = {
        method: "GET",
        headers: { Accept: "application/json", "x-api-key": mAPIKey },
    };
 
    let result = await fetch("https://api.dolby.com/media/analyze?job_id=".concat(jobID), options)
        .then((response) => response.json());
    console.log(result);
}

The checkJobStatus function may need to be run multiple times depending on how long it takes for the Analyze Media job to resolve. Each time you query the status you should get results where progress ranges from 0 to 100.

{
  "path": "/media/analyze",
  "status": "Running",
  "progress": 42
}

Once we know the job is complete we can download the resulting JSON which contains all the data and insight generated regarding the input media.

async function getResults() {
    //Gets and displays the results of the Analyze job
    let mAPIKey = YOUR_DOLBYIO_MEDIA_API_KEY;
 
    const options = {
        method: "GET",
        headers: { Accept: "application/octet-stream", "x-api-key": mAPIKey },
    };
 
    //Fetch from the output.json URL we specified in step 2.
    let json_results = await fetch("https://api.dolby.com/media/output?url=dlb://file_output.json", options)
        .then((response) => response.json())
        .catch((err) => console.error(err));
 
    console.log(json_results)
}

The resulting output JSON includes music data which breaks down by section. These sections contain an assortment of useful data points:

• Start (seconds): The starting point of this section.
• Duration (seconds): The duration of the segment.
• Loudness (decibels): The intensity of the segment at the threshold of hearing.
• Beats per minute (bpm): The number of beats per minute and an indicator of tempo.
• Key: The pitch/scale of the music segment along with a confidence interval of 0.0–1.0.
• Genre: The distribution of genres including confidence intervals of 0.0–1.0.
• Instrument: The distribution of instruments including confidence intervals of 0.0–1.0.

Depending on the complexity of the audio file there can sometimes be 100s of music segments.

"music": {
    "percentage": 34.79,
    "num_sections": 35,
    "sections": [
        {
            "section_id": "mu_1",
            "start": 0.0,
            "duration": 13.44,
            "loudness": -16.56,
            "bpm": 222.22,
            "key": [
                [
                    "Ab major",
                    0.72
                ]
            ],
            "genre": [
                [
                    "hip-hop",
                    0.17
                ],
                [
                    "rock",
                    0.15
                ],
                [
                    "punk",
                    0.13
                ]
            ],
            "instrument": [
                [
                    "vocals",
                    0.17
                ],
                [
                    "guitar",
                    0.2
                ],
                [
                    "drums",
                    0.05
                ],
                [
                    "piano",
                    0.04
                ]
            ]
        }

This snippet of the output only shows the results as they relate to the Cue Sheet use case, the API generates even more data including audio defects, loudness, and content classification. I recommend reading this guide that explains in-depth the content of the output JSON.

With the final step resolved we successfully used the Analyze Media API and gained insight into the content of the audio file. In the context of the Cue Sheet Palooza Hackathon, the participants were only really interested in the data generated regarding the loudness and music content of the media and hence filtered the JSON to just show the music data similar to the example output.

Building an app for creating Cue Sheets

Of course not every musician or composer knows how to program and hence part of the hackathon was building a user interface for SOCAN members to interact with during the Cue Sheet creation process. The resulting apps used a variety of tools including the Dolby.io API to format the media content data into a formal Cue Sheet. These web apps took a variety of shapes and sizes with different functionality and complexity.

It’s one thing to show how the Analyze Media API works but it’s another thing to highlight how the app might be used in a production environment like for a Cue Sheet. Included in this repo here is an example I built using the Analyze Media API that takes audio and decomposes the signal to highlight what parts of the media contain music.
Here is a picture of the user interface, which takes in your Media API Key and the location of a locally stored media file.

For showcasing the app I used a downloaded copy of a music review podcast where the host samples a range of songs across a variety of genres. The podcast includes 30 tracks which are played over 40% of the 50-minute podcast. If you want to try out the App with a song you can use the public domain version of “Take Me Out to the Ball Game” originally recorded in 1908, which I had used for another project relating to music mastering.

Feel free to clone the repo and play around with the app yourself.

Conclusion:

At the end of the hackathon, participating teams were graded and awarded prizes based on how useful and accessible the Cue Sheet tool would be for SOCAN members. The sample app demoed above represents a very rudimentary version of what many of the hackers built and how they utilized the Analyze Media API. If you are interested in learning more about their projects the winning team included a GitHub repo with their winning entry where you can see how they created a model to recognize music and how they used the Dolby.io Analyze Media API to supplement the Cue Sheet creation process.

If the Dolby.io Analyze Media API is something you’re interested in learning more about check out our documentation or explore our other tools including APIs for Algorithmic Music Mastering, Enhancing Audio, and Transcoding Media.

Searching Audio to Find Loudness and Music Sections was originally published in Hacking Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

The 1908 Jack Norworth and Albert Von Tilzer song “Take Me Out to the Ball Game” has been a classic staple across ballparks becoming synonymous with America’s favorite pastime. At over 114 years old, the original version of “Take Me Out to the Ball Game” was recorded on a two-minute Edison Wax Cylinder by singer and performer Edward Meeker, quickly becoming a beloved classic. With the baseball season getting underway this April 7th we thought it was about time to dust off the gloves, pick up our bats, step up to our Python environments, and get to work algorithmically remastering the classic anthem with the Dolby.io Music Mastering API.

Typically performed by audio engineers, Mastering is a labor-intensive post-production process usually applied as the last step in creating a song and is the final polish that takes a track from good to great. Because “Take Me Out to the Ball Game” was recorded and produced in 1908 the mastering and post-production technology was very limited and hence it could be interesting to explore the impact of applying a music mastering algorithm on the original recording, and the effect that has on the palatability of the track.

Picking a Version

Before we can get started remastering “Take Me Out to the Ball Game”, we first need to pick a version of the song. Whilst we often hear the catchy tune played during the middle of the seventh inning, that version isn’t the original and is subject to copyright protection. For this project, we will be using the 1908 version found here, as it is now available in the public domain and free to use. Unfortunately, the highest-quality version of the 1908 song is stored as an MP3. Whilst this works with the API, Free Lossless Audio Codec (FLAC) or other lossless file types are preferred as they produce the best results during the mastering post-production process.

The Music Mastering API

With our song in hand, it’s time to introduce the tool that will be doing the majority of the heavy lifting. The Dolby.io Music Mastering API is a music enhancement tool that allows users to programmatically master files via a number of sound profiles specific to certain genres and styles. The API isn’t free, however, Dolby.io offers trial credits if you sign up and additional trial credits if you add your credit card to the platform.

For this project, the trial tier will be sufficient which is available if you sign up here.

Once you have created an account and logged in, navigate over to the applications tab, select “my_first_app”, and locate your Media APIs API Key.

It’s important to note that all Dobly.io media APIs adhere to the REST framework, meaning they are language agnostic. For the purposes of this project, I will be using the tool in Python, however, it works in any other language.

Adding it to the Dolby.io Server

To utilize the Music Mastering API we first need to store the MP3 file on the cloud. This can be done with either a cloud service provider such as AWS, or you can use the Dolby.io Media Storage platform. For simplicity, we will use the Dolby.io platform which can be accessed via a REST API call.

To get started we need to import the Python “Requests” package and specify a path to the MP3 file on our local machine.

import requests #Requests is useful for making HTTP requests and interacting with REST APIs

file_path = "Take-Me-Out-to-the-Ball-Game.mp3"

Next, we need to specify the URL we want the Requests package to interact with, specifically the Dolby.io Media Input address. In addition to the input URL, we also need to format a header that will authenticate our request to the Dolby.io server with our API key.

url = "https://api.dolby.com/media/input"
headers = {
    "x-api-key": "YOUR DOLBY.IO MEDIA API KEY",
    "Content-Type": "application/json",
    "Accept": "application/json",
}

Finally, we need to format a body that specifies the name we want to give our file once it is added to the server.

body = {
    "url": "dlb://input-example.mp3",
}

With the URL, Head, and Body all formatted correctly we can use the Requests package to create a pre-signed URL to which we can upload our MP3 file to.

response = requests.post(url, json=body, headers=headers)
response.raise_for_status()
presigned_url = response.json()["url"]
 
print("Uploading {0} to {1}".format(file_path, presigned_url))
with open(file_path, "rb") as input_file:
    requests.put(presigned_url, data=input_file)

Starting a Mastering Job

Once the audio file has been moved to the cloud we can begin calling a mastering job. The Music Mastering API includes a number of predefined “profiles” which match up to a selection of audio genres such as Hip Hop or Rock. For the best results, a Rock song should be mastered with the Rock profile, however, the process of picking a profile can require a bit of experimentation.

Because matching creative intent with different sound profiles can take a few trials the API offers a “preview version” where you can master a 30 seconds segment of a song with 3 different profiles. We format the body of this request to include this information as well as when we want the segment to begin.

body = {
    "inputs": [
        {"source": "dlb://input-example.mp3", "segment": {"start": 36, "duration": 30}} #36 seconds is the start of the iconic chorus.
    ],
    "outputs": [
        {
            "destination": "dlb://example-master-preview-l.mp3",
            "master": {"dynamic_eq": {"preset": "l"}} #Lets master with the Vocal profile
        },
        {
            "destination": "dlb://example-master-preview-m.mp3",
            "master": {"dynamic_eq": {"preset": "m"}} #Lets master with the Folk profile
        },
        {
            "destination": "dlb://example-master-preview-n.mp3",
            "master": {"dynamic_eq": {"preset": "n"}} #Lets master with the Classical profile
        }
         
    ]
}

The Header stays the same as the one we used to upload the file to the Dolby.io Server and the URL changes to match the Music Mastering endpoint.

url = "https://api.dolby.com/media/master/preview"
headers = {
    "x-api-key": "YOUR DOLBY.IO MEDIA API KEY",
    "Content-Type": "application/json",
    "Accept": "application/json",
}

We can use the Requests package to deliver our profile selections and start the mastering job.

response = requests.post(url, json=body, headers=headers)
response.raise_for_status()
print(response.json())
job_id = response.json()["job_id"]

This process can take a minute to complete. To check the status of the job we can format another request to the same URL with the Job_ID included in the body to check the progress of the master.

url = "https://api.dolby.com/media/master/preview"
headers = {
        "x-api-key": "YOUR DOLBY.IO MEDIA API KEY",
        "Content-Type": "application/json",
        "Accept": "application/json",
    }
params = {"job_id": job_id}
response = requests.get(url, params=params, headers=headers)
response.raise_for_status()
print(response.json())

The response from the request outputs the progress of the job between 0% and 100%.

Downloading the Mastered File

With our file mastered it’s time to download the three master previews so we can hear the difference. The workflow for downloading files mirrors that of how the rest of the Dolby.io APIs work. Much like uploading a file or starting a job we format a header with our API key and a body that points to the mastering output on the Dolby.io server.

import shutil #File operations package useful for downloading files from a server.
 
url = "https://api.dolby.com/media/output"
headers = {
        "x-api-key": api_key,
        "Content-Type": "application/json",
        "Accept": "application/json",
    }
 
for profile in ["l","m","n"]:
 
    output_path = "out/preview-" + profile + ".mp3"
 
    preview_url = "dlb://example-master-preview-" + profile + ".mp3"
    args = {"url": preview_url}
 
    with requests.get(url, params=args, headers=headers, stream=True) as response:
        response.raise_for_status()
        response.raw.decode_content = True
        print("Downloading from {0} into {1}".format(response.url, output_path))
        with open(output_path, "wb") as output_file:
            shutil.copyfileobj(response.raw, output_file)

With the mastered files downloaded locally, we can listen to both and hear the difference between the original and one of our Masters.

Original file

Mastered Version

We can also hear the subtle differences between the Masters.

Mastered 1

Mastered 2

Mastered 3

For the purposes of this demo, we only mastered the last three profiles, however, there are 14 different music mastering profiles to pick from. From my testing, I like the “Classical” profile (Profile n) the best, but everyone is different, try it out yourself.

A More Modern Example

Whilst the classic still doesn’t sound modern, remastering the track does make it a little clear and hence more enjoyable to listen to. Typically the Dolby.io Music Mastering API is built for contemporary samples recorded on more modern equipment in lossless formats such as FLAC and is not designed to be an audio restoration tool. For the purposes of this investigation, we wanted to see the impact post-production mastering would have on the track rather than attempting to outright “fix” the original.

Currently, the Dolby.io team has a demo hosted here that lets you listen to before and after examples of licensed contemporary tracks which better exemplifies the use case of the API. Because Dolby.io owns the licenses to those songs they are allowed to host the content, whereas for this project we wanted to pick a track in the public domain so anyone with an interest can test it out for themselves without fear of infringing on copyright law.

If the Music Mastering API is something you are interested in further exploring check out the Dolby.io documentation around the API or the live demo mentioned above, otherwise let's get excited for an awesome Baseball season ahead and “root, root, root for the home team”.

“Take Me Out to the Ball Game” Algorithmically Remastered in Python was originally published in Hacking Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

Humans are great at classifying noises. We can hear a chirp and surmise that it belongs to a bird, we can hear an abstract noise and classify it as speech with a particular meaning and definition. This relationship between humans and audio classification forms the basis of speech and human communication as a whole. Translating this incredible ability to computers on the other hand can be a difficult challenge, to say the least.

Whilst we can naturally decompose signals, how do we teach computers to do this, and how do we show what parts of the signal matter and what parts of the signal are irrelevant or noisy? This is where PyAudio Analysis comes in. PyAudio Analysis is an open-source Python project by Theodoros Giannakopoulos, a Principle researcher of multimodal machine learning at the Multimedia Analysis Group of the Computational Intelligence Lab (MagCIL). The package aims to simplify the feature extraction and classification process by providing a number of helpful tools that can sift through the signal and create relevant features. These features can then be used to train models for classification or segmentation tasks.

So How Does it Work?

To get started with PyAudio Analysis we first have to install the package which can be done through the pip command in the command line:

pip install PyAudioAnalysis

Next, we can use the functionality of the package to extract features. With the feature extraction, there are two main methodologies we need to understand, Short-term features and Mid-term features.

• Short-term features are features calculated on a user-defined “frame”. The signal is split into these frames where the package then computes a number of features for each frame, outputting a feature vector for the whole signal.
• Mid-term features are features calculated on short-term feature sequences and includes common statistics such as mean and standard deviation for each short-term sequence.

Altogether the feature extraction creates 34 features for each frame that fits within the provided audio signal. For example with we have one minute of audio and set a frame length of 0.025 seconds our resulting matrix will be 34 by 2400 rows. These features include a variety of signal processing nomenclature and are briefly described in the table provided by the PyAudio Analysis wiki below:

These features can be generated for a series of audio samples through the command line. In this case, we have four parameters to specify with relation to feature creation, the mid-term window size (mw), the mid-term step size (ms), the short-term window size (sw), and the short-term step size (ss).

python3 audioAnalysis.py featureExtractionDir -i data/ -mw 1.0 -ms 1.0 -sw 0.050 -ss 0.050

Using these created features we can then train a classifier with the inbuilt features of the package. In this case, we are going to train a classifier that can distinguish the difference between two contrasting genres, sports, and business. For this particular example, we will use a k-Nearest-Neighbor (kNN) model which informs classification based on the relationship of the surrounding “k” neighbors, and we’ll train on a dataset of 20 20-minute sports podcasts and 10 20-minute business podcasts. The model will then be evaluated on a reserve dataset of 10 20-minute sports podcasts and 5 20-minute business podcasts. Under optimal conditions, we would use a significantly greater dataset of hundreds of audio samples, however, due to limitations in a catalog of audio samples we are only experimenting with 45 total podcast samples.

python3 AudioAnalysis.py trainClassifier -i raw_audio/sport/ raw_audio/business --method knn -o data\knnSM

The model takes about 15 minutes to train, before spitting out results relating to the training in the form of a Confusion Matrix and a Precision, Recall, F1, and Accuracy Matrix. The Confusion Matrix highlights a highly effective model with 100% accuracy despite the imbalance of the data with 66% of the samples belonging to “Sports” and 33% belonging to “Business”.

We can also look at the Precision, Recall, F1, and Accuracy Matrix to see how the model performed at different neighbor counts (c ), with both 1-NN and 3-NN performing the most accurately with the performance dropping off as more neighbors are considered.

With the model trained we can now evaluate its performance on unseen audio samples:

from pyAudioAnalysis import audioTrainTest as aT aT.file_classification("file_loc/sports_podcast.wav", "data/knnSM","knn")

aT.file_classification("file_loc/business_podcast.wav", "data/knnSM","knn")

As we can see the model is performing well, in fact, if we evaluate it on the remaining 15 test podcast samples we get an accuracy of 100%. This indicates that the model is generally effective and that the feature extraction process created relevant data points that are useful for training models. This experiment on business and sports podcasts serve as more of a proof of concept however as the training set and test set we relatively small. despite the limitations, this example highlights the effectiveness of feature extraction from audio samples using PyAudio Analysis.

In Summary

Being able to extract relevant and useful data points from raw unstructured audio is an immensely useful process, especially for building effective classification models. PyAudio Analysis takes this feature extraction process and simplifies it into just a few lines of code you can execute on a directory of audio files to build your own classification models. If you are interested in learning more about PyAudio Analysis the Dolby.io team presented a tutorial on audio data extraction at PyData Global that included an introduction to the package, or you can read more about the package on its wiki here.

Originally published at https://dolby.io on December 16, 2021.

Extracting Features from Audio Samples for Machine Learning was originally published in Hacking Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

From October 28th to the 30th I participated in PyData Global 2021, an event hosted by the non-profit educational program PyData, that focuses on helping connect, educate, and grow the data science community. Although Python is in the name, the event welcomes developers and researchers from all different backgrounds to share their tools and experience with the wider community.

For me this was my first data science event, having only graduated this year I had missed out on a number of conferences due to the pandemic and I was thrilled to finally be able to attend one, albeit virtually. Not only would I be attending the event I would also be representing my company Dolby and presenting two webinars, a short 10-minute lightning talk, and a full-length 90-minute tutorial.

As a first-time data science speaker and a recent graduate, jumping headfirst into the community was a daunting task and I wanted to share three things I learned along the way for anyone looking to get involved as a speaker.

What Was I Presenting?

For my presentation, I was focusing on educating and building the community around audio data. Audio data is an immensely rich and common data source however it can be difficult to use and has a steep learning curve. This learning curve can turn away beginners so I wanted to create a presentation highlighting some tools, tips, and tricks, as well as some rewards of working in the audio data space. To give the presentation more of a theme I chose to focus my investigation on podcasts, specifically a 20-episode sports series where we explored what we could learn from the podcast recordings. If you are interested in watching a recording of the presentation check it out here.

Do Your Research on the Community

The first thing I learned and probably the most important is to always do your research on the event, even after your CFP (call for presentations) has been accepted.

If you haven't attended the event before there may be some unseen rules or nuances to how presentations are conducted and how the community receives them. A great way to check this out is to watch past recordings of the events on YouTube, where you can get a feel for the tone and atmosphere of the community. Some events are more serious in nature and others are more casual, some are more academic and research-focused, and some are more industry-focused. Knowing the distinction can help make sure your work resonates with the audience’s expectations.

Here are a few good questions to ask when preparing a presentation:

1. How much code am I expected to show and where should I show it?
2. What level of aptitude am I expecting from my audience?
3. Should I prepare a script or adlib for a more casual feel to the presentation?
4. Is my presentation applicable to the wider community or just a subset?
5. How can I make sure my figures and code are legible to viewers?

Depending on the answers to these questions you might format your content in a certain way to better cater to the audience.

Interact with the Audience

If you have ever watched a Livestream on Twitch you’ll know that a good streamer interacts with their audience regularly. This isn’t just to kill time, the connection between the audience and host is an important one and can make or break live content, especially content that is hours long.

This relationship between the viewer and the host is no different at tech conferences and can be more important depending on the difficulty of the content.

There are a number of different tactics I employed to help my audience feel more connected to the content and the presentation. Some of these tactics are obvious such as stopping to answer questions or reading comments out loud, which can help the audience engage with the content as well as demonstrate your own command of the material you are presenting. If you want to really engage your audience you can explore ways to make the viewers think critically about your content. In my audio data presentation, I linked a Typeform for attendees to fill out with their own project ideas for how they could use audio data. To further incentivize responses I offered bonus usage minutes to Dolby.io media API for any ideas I liked and want to see explored. This helped viewers feel more connected to the content and the presentation as well as allowed me to pad out the session with some more casual discussion on some of the ideas.

Also included in the TypeForm was a section to gather feedback on the presentation where I got some great comments from an awesome audience.

Share Your Code!

The final major takeaway I got from my first tutorial was to have code ready to share. Even if you don’t include much code in your actual presentation having some demos ready to share with the audience is a must, especially at data science events where the audience expects IPython notebooks.

Sharing code can help the audience in a number of ways from catering to different kinds of learners to helping reiterate key components of the presentation. I opted to include two code resources for the tutorial:

1. My Presentation Code, This repo included two notebooks that created the data and a notebook that analyzed the data.
2. Awesome Audio, This repo included a number of audio data resources include how-to guides, datasets, audio samples, and much more. Check it out if you are interested in contributing.

These resources helped improve the reproducibility of my results and presentation as well as helping the audience with some resources to get started if they want to do something similar.

Final Comments

Public speaking, even if virtual, can be a daunting experience no matter your background. My advice to anyone looking to get started, beyond what I mentioned above, is to get involved with the community. It's incredibly supportive and full of many people happy to pass on some advice. Who knows you might even get some kudos along the way:

Fantastic talk. It is unfair to judge but if I had to it would be my in top 3 out of 35 or so talks that I listened to. Thank you.

Three Tips I Learned Presenting at My First Tech Conference was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.