Verarbeitung #347: Additional validation of frame rate / sample width - collecting_society - C3S Tracker

Verarbeitung #347

Additional validation of frame rate / sample width

Added by Alexander Blum about 7 years ago. Updated over 4 years ago.

Status:

Erledigt

Start date:

05/03/2017

Priority:

Niedrig

Due date:

05/10/2017

Assignee:

Alexander Blum

% Done:

100%

Category:

Estimated time:

0.50 h

Target version:

Repertoire 4) Production phase I

Description

Concerning the policy for high quality audio files, should we also define constraints on the frame rate and/or sample width? Do such constraints restrict the freedom of art (like 8 bit music)?

Related issues

Associated revisions

Revision 7f080ae2
Added by Thomas Mielke almost 7 years ago

reject it sampling rate < 1 byte (redmine ticket #347)

forgot to remove debugging code

History

#1 Updated by Thomas Mielke about 7 years ago

Assignee changed from Thomas Mielke to Alexander Blum

Yes, a minimum wav sampling rate or bit width crosses a red line -- while someone can argue, even if mp3 is the official master format, it's just a lossy compression, not an audio format by itself, this wouln't be true with sampling rate or bit width restrictions. Although, as we have 11.025 Hz / mono as fingerprinting format, there would be a point using this as minimum sampling rate. But I wouldn't restrict it anyway.

#2 Updated by Alexander Blum about 7 years ago

Assignee changed from Alexander Blum to Thomas Mielke

Even music with e.g. 1 bit or 1000 Hz?

#3 Updated by Thomas Mielke about 7 years ago

Assignee changed from Thomas Mielke to Alexander Blum

Don't be so narrow-minded! :D

Ok, 8 bit 11.025 Hz mono maybe a good compromise between conservative quality considerations and freedom of format.

#4 Updated by Alexander Blum about 7 years ago

Subject changed from Additional validation of frame rate / sample width? to Additional validation of frame rate / sample width
Assignee changed from Alexander Blum to Thomas Mielke

Then I suggest - you may have expected it - another state 'validated' :)

This process stage should be

the very first stage
equally frequent as preview
extract the audio features for the database (sample width, frame rate, ...), which could the problem, that I may need this information soon

This stage would be the place for all future validation checks that may come.

Errors should result in rejected state (reason: format_error).

Agreed?

#5 Updated by Thomas Mielke about 7 years ago

Assignee changed from Thomas Mielke to Alexander Blum

But we get these informations for free in the preview step. Makes no sense to me.

#6 Updated by Alexander Blum about 7 years ago

Assignee changed from Alexander Blum to Thomas Mielke

I quote yourself :)

clear separation of concerns is more important than functional similarities.

#7 Updated by Alexander Blum about 7 years ago

But yes, I forgot, that the audio feature extraction is done in the preview stage, so there's no additional gain there.

#8 Updated by Thomas Mielke almost 7 years ago

Due date set to 05/10/2017
Status changed from Feedback to In Bearbeitung
Assignee changed from Thomas Mielke to Alexander Blum
Start date set to 05/03/2017
% Done changed from 0 to 80

the sample width is provided in bytes by pydub and only converted to bits in our code, so it's unlikely that it's < 8 bits, anyway, I do a nullcheck now.

https://github.com/C3S/c3sRepertoireProcessing/commit/7f080ae22c3bdb00d87c575d7ad22ce779721c15

I want an additional string field in content named 'rejection_reason_details'. Maybe rename rejection_reason to rejection_reason_class for clarity then?