get up to date with the main branch to then merge fork into main branch #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The docs for np.interp say: > The x-coordinate sequence is expected to be increasing, but this is not > explicitly enforced. However, if the sequence `xp` is non-increasing, > interpolation results are meaningless. Turn this into an explicit failure. In theory we could sort xp and yp, but this algorithm doesn't make any sense if the edges are beyond 180 degrees.
This is not in the spec, but if these errors are raised then screen scaling would have failed silently before.
This is primarily a -1 feature; multiple loudnessMetadata elements are supported for compatibility with -2. Co-authored-by: Tom Nixon <[email protected]>
add some wrappers in case the API changes again
The spec isn't explicit about how X, Y and Z size should map to width, height and depth, but that is listed in table 16 of BS.2076-2, and this way around is reasonably obvious. Add some tests which check that the orientation looks correct in both directions.
The intent of this line was to produce a vector containing the index of
each number in priority_order:
np.arange(len(layout.channels))[priority_order]
but this does nothing; the result is the same as priority_order.
In this case the spec and the original intent was correct; this
behaviour makes no sense. The existing tests aren't too bad, we were
just unlucky in that the order in 4+5+0 used for the tests happened to
be correct.
explicitly check the channel order, and add a case which failed with the old implementation
This matches conventions used for everything else, and does not really create a compatibility issue as it was never exported.
other types have default ImportanceData objects (not None), so this is more consistent
all blocks now have importance, so this only doesn't apply to HOA, which doesn't have blocks in rendering items
- test filter_by_importance rather than an implementation detail - check that the whole type metadata is copied - make it possible to use the same structure for other single-channel types
- use evolve instead of modifying data - use a generic MetadataSourceMap instead of MetadataSourceImportanceFilter
fixes #53 The specific bug is that whenever the result would contain multiple distinct packs which only contain silent channels, multiple equivalent solutions would be produced. This could cause an "Ambiguous format references" error when the references from an audioObject are not in fact ambiguous. The data that triggers this is not useful, and causes an error (rather than incorrect behaviour), so it was likely never triggered in the wild. When allocating new packs for silent tracks, the packs need to be allocated in order, to avoid allocating both [p1, p2] and [p2, p1] with silent tracks, as in the original bug. This is implemented by modifying the list of possible packs to allocate in subsequent steps, by creating remaining_packs in candidate_new_packs, and threading that through.
this will be used for testing the main implementation the intent was to make this much simpler than the main implementation, but that wasn't possible
add a test helper which checks the results of all implementations against each other, and some basic properties (count or equality)
- no AXML or CHNA: this used to throw an exception when accessing chna.audioIDs; now .adm is None - AXML present, but missing CHNA chunk: same error; now throws a more meaningful error as this is not valid
Previously, validation only worked if there was one audioContent in an audioProgramme with alternativeValueSets. This also changes the intended behaviour, so that an audioProgramme and a contained audioContent can not reference the same alternativeValueSet. This is done because if an audioContent references an alternativeValueSet, there is no need to reference it from the audioProgramme. This turned into a general refactor of this validation, because the old code had the wrong structure to be able to work properly.
These are supposed to be based on the type (from the channel/pack format), but were based on the format (i.e. always PCM, or 0001). closes #76
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.