In viewing the draft catalogue for SRKW calls today (and in recent weeks), I've found a small selection of the audio samples displaying an "Access Unavailable" graphic. Upon inspection when I select the play button under one of these graphics, there is a 404 error (see screenshot).

Maybe a file name changed, or a sample was removed from the catalogue's media directory?

A couple days ago and again today, I tried to access the catalog for further reference and beta-testing. I got this page upon seeking the catalog --

-- and this 502 error when I backed out to the sub-domain itself --

Feature request

It would be slick if license information for end-users and rendered at https://orca.research.sfu.ca/catalogue/license.html could be generated automatically from information maintained in the Github repo. Then, as new versions of a catalogue are agreed upon and issued (via Github version control) then the attribution could be specified more clearly than it currently is on the license page.

Proposed solution

For example, instead of the current stipulation --

You must, where you do any of the above: Acknowledge the source of the Information by including any attribution statement specified by the Information Provider(s) and, where possible, provide a link to this license.

-- automated code could instead render something like this message --

You must, where you do any of the above, acknowledge the source of the Information by this attribution statement "Orca call Catalogue version 1.0 by Ford, et al. (2023)" and, where possible, provide a link to this license.

Some future version might instead specify attribution to "Orca call catalogue version 2.0, Wieland, et al., 2023" but in both cases all the contributors to a particular version would receive some credit on the license page, e.g. through automated listing of all contributors to that version based on the git history within the repo.

The front end contains a mix of Bootstrap elements and W3. The original prototype (early 2022) used Bootstrap elements. Newer elements (navbar, license.html, maybe others; late 2022) use W3 elements.

• Bootstrap alternatives exist for a navbar and for the elements used in license.html.
• Navbar changes are a lower priority as it will likely be replaced with a navbar consistent with the landing page; however, it may be a priority for end users: Ruth, John

The word license is misspelled as licence in many places, at least these two pages:

1. https://orca.research.sfu.ca/johnf/faq.html#how-to-use-this-site
2. https://orca.research.sfu.ca/catalogue/license.html

Both the title of the LICENCE page and the menu item it are misspelled.

Also, on the license.html page, in its last sentence, the word referring is misspelled as refering --

J pod is in Puget Sound for the 3rd time this fall and I'm trying to help a listener decide if she is hearing S3 calls.

Unfortunately, at least on Chrome+OSX I'm getting 404s when selecting all the play buttons from https://orca.research.sfu.ca/catalogue:

@git-steb It seems the UI for SRKWs is getting less usable, rather than close to a public launch! :(

Problem:

Today I loaded the page and was scrolling down through the SRKW items to find a match to a call in an Orcasound recording of J pod. I was surprised when the catalog ended at the S05 call! Eventually, I realized that this was because the default number of items to load had been reduced to 24. I assume this was done to decrease page load time...

...but the problem is that now when I'm scrolling or searching for a particular call that's listed in the catalogue after S05, I have to change the default number of items to 240. This is annoying and time-consuming when I'm using the catalogue frequently!

Proposed solution:

If performance requires loading fewer items by default, then I suggest listing a single sample for each call type by default. In the current SRKW catalog, that will result (on my OSX+Chrome desktop) in a 6 column x 5 row grid containing all 30 call types. To subsequently display the variability within each call type, the user could toggle a UI element -- either in the top area for all the call types, or maybe within the single call example -- to show variability only within that call type (i.e. for S01, toggling the variability switch would show all four examples of the S01 call).

The catalog-viewer repository needs a license, choosealicense.com, the simplest and most permissive is the MIT license.

The above is different than the license srkw-catalog-files (license.md) which is a license for the content (i.e. calls) in the John Ford's repository (https://orca.research.sfu.ca/catalogue/license.html). Candidates are:

• Open Government License – Canada
• chosealicense.com -> My project isn’t software

I have encountered strange behaviour viewing the catalog (https://orca.research.sfu.ca/catalogue) in my Safari browser (13.1.2; OSX 10.13.5 High Sierra; clearly outdated).

The waveform image for the first sample of call S01 has a different/inconsistent shape than the rest. This issue was addressed in an old commit and was presumed resolved. When viewed with Chrome/Firefox, the shape is consistent with the rest of the waveforms. Since this was not reproducible in @git-steb's Safari (current version) browser, I ignored the issue during development and attributed it to my old OS.

The expectation is that all waveform images are the same size/shape (the smaller square and not the rectangle).

Safari Screenshot:

Chrome Screenshot:

The issue is not observed when the calls are filtered to exclude S01 (to see if the issue is with displaying the first waveform)
Safari Screenshot:

Safari inspecting the S01 image:

The Toast notifications were fixed and additional samples were committed on (b381a1a) on branch front-end,

Based on meeting discussions, the use of Toast has been removed in the subsequent commits. The License information from the Toast is moved to a separate page.

On behalf of @JKBF and @oliviamurphy8:

“One bug I’ve found is that when I click to the next page of calls in the catalogue (at 24 items per page, if I’m page 1 of calls and I click on 2 to go to the next page), the play button for calls on the next page always only play the call that was in that position on page 1.”

I tried to access the catalogue (Chrome, MacBook) when I was visiting Orcasound Lab on the west side of San Juan Island. At this location in Washington, the download bandwidth is pretty limited (5 MB/s down; 0.1 MB/s up).

The catalog loaded slowly, taking 30-60 seconds to complete, possibly due to other traffic on the LAN. This seems to be due to the images having a file size of about 100kB and the initial/default view of catalogue involving some 90 images. That's about 10MB which could result in a similar performance issue on e.g. mobile devices.

I'm pretty sure I had already loaded the catalogue in this location on this browser+device, so am wondering whether there is a way to force the catalogue code to use cached images first, rather than downloading again?

Alternatively, this issue could motivate a simplified initial/default view -- e.g. one that presents only one example of each call type first, then gives an option to download/view more examples subsequently...

Tried to access S04 call examples this weekend while annotating Orcasound bouts, but failed to load catalogue via https://orca.research.sfu.ca/catalogue/...

As a bioacoustican listening live to the beautiful NRKW calls right now (11/30/22 12:00 Pacific),
via OrcaLab's Explore.org stream in Johnstone Strait,
I would like to use the call catalogue to learn a few of the A1 clan calls.

When I filter for NRKW calls, there are no samples:

Currently the number of examples provided for each of the SRKW calls varies a lot: from

2 S08s and S14s and S42s

to

13 S19s

In the long run, it might be nice to aim for a consistent number across all signal types for a catalogued repertoire. For example, if there were 4 "ideal" examples of each type, then a future UI could offer them in a 4-column grid, so that one's eye could more quickly scan down the grid for the next call type or a specific call type of interest...

Follow the open source project guidelines and the pre-launch checklist

Checklist cp here:

Ready to open source your project? Here’s a checklist to help. Check all the boxes? You’re ready to go! Click “publish” and pat yourself on the back.
Source: https://opensource.guide/starting-a-project/#your-pre-launch-checklist

Documentation

-[x] Project has a LICENSE file with an open source license
-[x] Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
-[x] The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
-[x] The issue queue is up-to-date, with issues clearly organized and labeled

Code

-[ ] Project uses consistent code conventions and clear function/method/variable names
-[ ] The code is clearly commented, documenting intentions and edge cases
-[x] There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)

People

If you’re an individual:
-[ ] You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)

If you’re a company or organization:
-[ ] You've talked to your legal department
-[ ] You have a marketing plan for announcing and promoting the project
-[ ] Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
-[x] At least two people have administrative access to the project

As a bioacoustic expert wanting to explore or teach a new listener about a single signal type,
I want to be able to quickly view* only* that call type (but all examples of it),
so that I can study, explain, or characterize its variability.

Proposed solution:

Somewhere near these filtering UI elements --

-- add a "Show only" element that, when selected, would show a menu of all signal (e.g. "call") types in the current filtered view. The user could then select one signal type from the menu and the current view would be (further) filtered.

A bonus would be for the UI element to allow more than one signal type to be selected (e.g. via a modal showing checkbox for each signal in the current view?). That could allow me to quickly explain or examine the difference between two signal types, like explaining how S16 is similar to but less monotonic than S17 in the J clan repertoire.

In using the prototype, I've found that I have questions for John about individual examples of the SRKW call types. In asking him the question, it would be nice to be able to provide a URL that unambiguously points to the audio file and/or spectrogram in question. Instead, I have to dig into the source code or make screenshots and recordings to get clarification that would eventually improve the catalog for a future version...

Ideally each sample would include only the stereotyped pulsed call. In this case the S09 has a leading S04 right before it, right John, et al.? :

• https://cs-bahamas.cmpt.sfu.ca/catalogue/simple/BCS09-J01pod-J02,J07,J08andJ09mat-2.jpg
• https://cs-bahamas.cmpt.sfu.ca/catalogue/simple/BCS09-J01pod-J02,J07,J08andJ09mat-2.wav

This issue is a particularly high priority for the S09 call type because the third example provided by John also has a fainter, brief S04 at the beginning of the S09:

• https://cs-bahamas.cmpt.sfu.ca/catalogue/simple/BCS09-Jpod.jpg
• https://cs-bahamas.cmpt.sfu.ca/catalogue/simple/BCS09-Jpod.wav

Together, this could confuse a listener into thinking the S09 always begins with a low-frequency buzz-like part (when it is actually a preceding S04 call).

This bug report is written on behalf of John Ford (@JKBF).

We encountered an issue viewing the catalogue in the Safari browser (M1 Mac; so we know it's relatively new) on John Ford's computer. When the play button was clicked, the sound was not played and the button was "stuck" playing (green). Clicking on the x was able to close the modal popup.

Chrome did not encounter this issue.  We want the catalogue to support Safari and other modern (Chrome/Firefox/Edge) browsers.

The screenshot (taken in MS Edge) shows the page where the issue was observed by @JKBF.

@git-steb Can you remind me and @veirs where the image and audio files will be stored?

I think the plan was to create a separate repository to hold such media? And then (auto?) generate a yaml file that would list all the resources in a catalog (SRKWs initially, but eventually other ecotypes, and then species)?

With more insights into your plan for deploying the viewer and media as separate repos, we could reformat parts of Emily's humpback catalogue repo to have a consistently-organized media folder...

Content for FAQ page of the catalogue website by @JKBF

Hey @JKBF !

Using the dictionary this morning to analyze J pod pass this morning at Val's place, I noticed a handful of your recordings have some prominent system noise at low frequencies. For example, there is substantial 60 Hz hum in this S22 example). You can see the 60 Hz harmonic and fundamentals in this power spectrum from the last ~20% of the clip:

Would you like me to use Audacity to reduce or remove the noise, e.g. with a high-pass filter?

Here is a new version of the S22-L-4.wav sample after post-processing (12 dB de-noising, 48 dB high-pass filter at 1kHz, another 12 dB de-noising, and then amplification to standard levels).

If you think it's worthwhile now, I could propose a list and potential improvements. Once you approve the list, I could download the samples, process, and return to a (post-processed) archive of SRKW samples.

I personally think this sort of cleaning of field recordings is low priority for the first version of this new SRKW catalog, and could be postponed for a future version. I'm more interested in getting a new tool into the "wild" and available for Orcasound community scientists, but wanted to flag noisier recordings as an issue to possibly be addressed at some point!

Same as Issue 4 of srkw-call-catalogue-files

I suspect it is because the payload sends commit messages, and some messages contain characters ", ( and ), ' which are being echoed without escaping in the manual deployment action

The issue does not occur with

• manually triggered deployment
• The automatically triggered GH Webhook feature (Settings -> Webhook -> on push)
  • The limitation of the webhook is that response status messages are not sent back since the token is missing in its payload

All the current catalogue's S10 examples have a short "buzz" at the beginning, preceding the "squeaky balloon" tonal modulations. I feel like many recent examples from Orcasound hydrophones don't include the buzz, but this could be due to attenuation or directionality of the buzz part causing the hydrophone to miss sensing it...

Here are some examples:

1. I don't hear it in the clip we're using in the "latest" online catalog at Orcasound (though it's apparent in John's old B&W spectrogram)
2. I don't hear it in these S10 examples from an L pod bout.