feat(starr): expand dual audio regex

[adapowers]

Pull Request

Purpose

Two common conventions for indicating dual audio releases are not currently captured by the regex:

• The release group VARYG appends it directly to their name: DUAL-VARYG
• Other release groups will use DUAL {Resolution} or {Resolution} DUAL

I attempted to add a pattern which was flexible, while having a low risk of false positives.

Approach

The following patterns have been added into the regex:

(?-i)DUAL-VARYG(?i)

• (?-i) disables case-insensitivity for the rest of the pattern
• DUAL-VARYG matches literally
• (?i) turns case-insensitivity back on for the rest of the pattern

dual[ ._-]?(\d{3,4}p|ultrahd|4k)

• dual[ ._-] matches dual (case insensitive) plus common separator characters
• \d{3,4}p|ultrahd|4k matches any 3-4 digits followed by p (1080p, 720p, etc.) or 4K or UltraHD

(\d{3,4}p|ultrahd|4k)[ ._-]?dual

• Same match as above, but in reverse order: 1080p.DUAL, 4K UltraHD DUAL, etc.

Notes:

• I did not choose to mess with case sensitivity lightly; as dual is a dictionary word, we want to prevent matching on any uppercase, hyphen-delimited filename that contains it. This is the same reason I chose to encode the release group directly. Without both, there could be too many false positives.
• In general, this approach attempts to leverage the fact that DUAL (as a single word indicating dual audio) is often placed directly before or after the video resolution.

Regex

https://regex101.com/r/p1Rt67/6

Open Questions and Pre-Merge TODOs

Requirements

• These changes meet the standards for contributing.
• I have read the code of conduct.

[adapowers]

Another thought: it would be nice if this could also be captured in the {custom formats} for renaming, to better track which files have dual audio and which don't. But that would require it having a shorter name like DA or Dual, which I imagine we wouldn't want. Any thoughts, besides simply changing the name on our own instances?

[adapowers]

Another thought: it would be nice if this could also be captured in the {custom formats} for renaming, to better track which files have dual audio and which don't. But that would require it having a shorter name like DA or Dual, which I imagine we wouldn't want. Any thoughts, besides simply changing the name on our own instances?

Ah, nevermind—I realized that's already accounted for in the {MediaInfo AudioLanguages} piece of the recommended anime naming scheme.

[FonduemangVI]

@rg9400 could I get you to take a look at this given the regex changes

[zakkarry]

could probably be improved further but this seems to do the same job.

not sure why the varyg is case sensitive, that seems like its unnecessary - when would this be lowercase and not be a match?

[adapowers]

could probably be improved further but this seems to do the same job.

not sure why the varyg is case sensitive, that seems like its unnecessary - when would this be lowercase and not be a match?

Fair enough—I think I was just trying to be super safe, but you make a good point. And I appreciate the additional refactor! Changes accepted.

still needs review from anime team - my changes have been committed

[rg9400]

Sorry, was on vacation for the last few weeks. Can you share some test cases against this regex? The VARYG format has Dual-Audio in their naming near the end which matches even if DUAL-VARYG does not. The dual regex you shared matches scene naming, but anime is rarely consistent, so it's not always the case that the resolution follows DUAL. For example, it's not matching NanDesuKa's format: Helck.S01E16.1080p.HIDI.WEB-DL.DUAL.AAC2.0.H.264-NanDesuKa.mkv. Another random example: [OhDeer] Shikanoko Nokonoko Koshitantan - 01 (WEB 1080p Multi Audio) | (Dual) (My Deer Friend Nokotan). I get that if we are too lenient, it can match episode and anime titles that use the word dual, but I am not sure how many additional releases it is capturing.

The regex itself looks good, but sometimes it's hard to identify potential issues, so just trying to do a bit of due diligence to validate the changes are solving a problem.

[FonduemangVI]

@rg9400 given your recent changes is this still valid/needed?