search

cta-wave / mezzanine

This repo contains scripts that will build annotated test content from specific source content, compatible with the WAVE device playback test suite.
BSD 3-Clause "New" or "Revised" License
2 stars 2 forks source link

additional white noise mezzanines required #41

Closed yanj-github closed 2 years ago

yanj-github commented 3 years ago

Can you kindly create another 60 seconds mezzanine same as what is it there now, but with different seed please? We would like to have seed noted on the file name if possible.

We also required white noise mezzanines main and ad for splicing test if you can help to create them as well please?

cta-source commented 3 years ago

Can I also suggest we choose 2 PN seeds and document them in the annotations spec? Then use "PN1" or "PN2" in the filename?

yanj-github commented 3 years ago

Can I also suggest we choose 2 PN seeds and document them in the annotations spec? Then use "PN1" or "PN2" in the filename?

We dont have specific requirement for seed if we can read it from the file name then it is fine. What is PN stands for please? Do you want to suggest splicing main and ad seeds as well please if you wish?

jpiesing commented 3 years ago

@cta-source @yanj-github Please explicitly agree what you want & don't expect @nicholas-fr to do anything unless/until you have reached agreement.

cta-source commented 3 years ago

@jpiesing , totally agree--I'm hoping to intercept any "production" path mezzanine audio files while we get documented agreement. @nicholas-fr has put together a spec for these kinds of details in the mezz annotations. I'll discuss here and if we are OK, I'll edit his draft with the results.

Regarding "PN", sorry, that's an abbreviation for Pseudo-Noise, which is what we're getting with the Python numpy.random library methods. The term PN is commonly used in signal processing to indicate not-actually-random-but-random-like sequences.

I think we already discussed that the Python libraries for PN sequences aren't long-term reproducible. Changes in the library may result in equally valid PN sequences that don't match what we're using now. So we need to work from static copies of our defined PN sequences. In other words, the test code must draw the PN sequence from a WAVE-validated file, not from a library call. That's easy, we just need to archive the PN sequences.

Another dev note, when converting ASCII to decimal to create the entropy seed, we need to make sure we use leading zeros. E.g., for ascii("P"), use "080" rather than "80". Using the shorter form results in less than 32 bits of entropy (about 26 bits). This should actually still work fine, either way, but we need to have a consistent approach. Note that the current audiomezz.py does NOT add leading zeros, so if we make this change we need to be consistent.

I recommend we set up some kind of structure like the following: <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

Seed Source String | Seed | Use | MD5 Hash -- | -- | -- | -- test | 116101115116 | Development purposes | A18D8B6BEF5A37C2018EA02E7A0B3F5A PN01 | 80078048049 | Primary content, production code | 3A2E4B3B41FED078241A02DE6848ACA9 PN02 | 80078048050 | Ad (spliced) content, production code | 144A3E6C0D4D4F4EC42D35C9BD2E00ED PN03 | 80078048051 | Spare No. 1 | 72F92675E263E5AFD0F34FA5EE70DCE0 PN04 | 80078048052 | Spare No. 2 | 7120086841ECB45721D9CE89A7E5D732

Then we can embed "PN01", etc., in the file names. But will we have files with multiple PN sequences? Seems like the splice tests would? So we'll need a convention to indicate this as well?

--MJB

Edit: Removed the leading '0' from the values in the table ("080078048049" -> "80078048049") for clarity (it's an int, not str). Edit #2: Added MD5 hashes, this is to keep this Issue consistent with the mezz spec, which is where this info will be formally kept.

yanj-github commented 3 years ago

Thanks @cta-source ,

We have test mezzanine white noise already. I would like to have 2 white noise for main testing and swithing testing. And 2 white noise for splicing tests, one main one is ad.

Seed Source String | Seed | Use | MD5 Hash | Duration -- | -- | -- | -- | -- test | 116101115116 | Development purposes | A18D8B6BEF5A37C2018EA02E7A0B3F5A | 60 PN01 | 80078048049 | Primary content, production code | 3A2E4B3B41FED078241A02DE6848ACA9 | 60 PN02 | 80078048050 | Secondary content, production code | 144A3E6C0D4D4F4EC42D35C9BD2E00ED | 60 PN03 | 80078048051 | Main (spliced) content | 72F92675E263E5AFD0F34FA5EE70DCE0 | ? PN04 | 80078048052 | Ad (spliced) content | 7120086841ECB45721D9CE89A7E5D732 | ?

Duration for Main (spliced) content and Ad (spliced) content should match the duration of mezzanine that we have for video so that we can do sync. @cta-source are you happy with this?

cta-source commented 3 years ago

Hi Yan, sounds very reasonable. However, I'm not clear on one point.

Duration for Main (spliced) content and Ad (spliced) content should match the duration of mezzanine that we have for video so that we can do sync.

Is that the 60s duration? Or will it be something else?

I'm working now with 60s durations.

yanj-github commented 3 years ago

Hi Yan, sounds very reasonable. However, I'm not clear on one point.

Duration for Main (spliced) content and Ad (spliced) content should match the duration of mezzanine that we have for video so that we can do sync.

Is that the 60s duration? Or will it be something else?

I'm working now with 60s durations.

As far as I know splice main has different duration please see this: https://dash-large-files.akamaized.net/WAVE/Mezzanine/under_review/2021-08-05/

cta-source commented 3 years ago

I think we can use the first (e.g.) 15 seconds of a 60-second PN file, can't we? Rather than make a file for each length, let's just have one for the longest requirement (60 seconds?) and truncate as needed. Would that work for you?

yanj-github commented 3 years ago

I think we can use the first (e.g.) 15 seconds of a 60-second PN file, can't we? Rather than make a file for each length, let's just have one for the longest requirement (60 seconds?) and truncate as needed. Would that work for you?

Yes that is fine with us.

yanj-github commented 3 years ago

@cta-source We can shorten the lenght within the encoding process for splice main to match video duration. Can you kinldy list down the content that you would like to have so that @nicholas-fr have clear idea of what to generate please?

cta-source commented 3 years ago

OK, after some realtime discussion, here's what we've agreed upon. Four PN files, as described above, plus one music file with an embedded copy of PN01, for test purposes.

Very important for devs: The hash codes of PN01-PN04 have changed because we went from stereo noise to Lch noise. The files are different, so the MD5 hash is different. Please see below.

Seed Source String | Seed | Use | MD5 Hash | Duration -- | -- | -- | -- | -- AdagioPN01-12dB.wav | n/a | Development purposes | A6C14824708CB8A96FE91D1F2E838F84 | 60 PN01.wav | 80078048049 | Primary content, production code | 98626CE9659298B9316A26DE2C92AE91 | 60 PN02.wav | 80078048050 | Secondary content, production code | 19DEC56E552A5848CAD0350C2994A704 | 60 PN03.wav | 80078048051 | Main (spliced) content | D12AB69985A3E6A7B88CA4911FC46EBA | 60 PN04.wav | 80078048052 | Ad (spliced) content | BCE7DC0250E359306E3EC490416B4453 | 60

I've passed copies of the files, the hashes and the code used to generate the noise to Yan for her review. If this all works as expected, these files will be part of the next release. We may also maintain testout.wav; I'm not using it but Eurofins may have a use for it.

cta-source commented 2 years ago

The PN01-PN04 files, purposes and hashes listed above are finalized and in the current "research" repo. The AdagioPN01 file is not used.

Closing this issue as we have agreed on the above table (less the Adagio file).

yanj-github commented 2 years ago

@cta-source Can you point me to the repo where these are shared please? I dont see "research" folder on akamai. Are they shared elsewhere?

cta-source commented 2 years ago

They are in a repo at cta-source/audio-watermark-study for now. We had not yet agreed to move this to the WAVE repo area. I'm not sure we want a dedicated repo under WAVE just for this little project, I was thinking we would leave the code in this 'research' repo until we merge with the OF. What do you think?

yanj-github commented 2 years ago

They are in a repo at cta-source/audio-watermark-study for now. We had not yet agreed to move this to the WAVE repo area. I'm not sure we want a dedicated repo under WAVE just for this little project, I was thinking we would leave the code in this 'research' repo until we merge with the OF. What do you think?

Thanks, Mike. Certainly we can wait this to be agreed with the group. However, please note that there are already final encoded contents eac3 and ac4 from this source already on content pool.

cta-source commented 2 years ago

However, please note that there are already final encoded contents eac3 and ac4 from this source already on content pool.

Noted, thanks. As this isn't a current priority (use of audio watermarks), it should not be a problem to leave things as-is.