Uploaded image for project: 'Zapped: AcousticBrainz'
  1. Zapped: AcousticBrainz
  2. AB-404

Provide an API endpoint where users can select only the features that they want returned

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Normal Normal
    • None
    • None
    • None
    • None

      Sometimes a user of the API might want only a small amount of data for a given musicbrainz id, for example BPM or key.

      We should add the functionality to the bulk get API to allow a feature filter that lets users select just some items. These items should be hard-coded, and we can map it to a field in the json document - that is, we shouldn't allow users to provide arbitrary postgres json queries in the parameter.

      It's not clear if we should allow a single endpoint to return both highlevel and lowlevel information, or if we should keep these endpoints independent.

      Features that should be selectable:

      lowlevel.average_loudness, lowlevel.dynamic_complexity, metadata.audio_properties.replay_gain, rhythm.beats_count, rhythm.beats_loudness.mean, rhythm.bpm, rhythm.bpm_histogram_first_peak_bpm.mean, rhythm.bpm_histogram_second_peak_bpm.mean, rhythm.danceability, rhythm.onset_rate, tonal.chords_key, tonal.chords_scale, tonal.key_key, tonal.key_scale, tonal.tuning_frequency, tonal.tuning_equal_tempered_deviation

          Loading...
          Uploaded image for project: 'Zapped: AcousticBrainz'
          1. Zapped: AcousticBrainz
          2. AB-404

          Provide an API endpoint where users can select only the features that they want returned

            • Icon: New Feature New Feature
            • Resolution: Fixed
            • Icon: Normal Normal
            • None
            • None
            • None
            • None

              Sometimes a user of the API might want only a small amount of data for a given musicbrainz id, for example BPM or key.

              We should add the functionality to the bulk get API to allow a feature filter that lets users select just some items. These items should be hard-coded, and we can map it to a field in the json document - that is, we shouldn't allow users to provide arbitrary postgres json queries in the parameter.

              It's not clear if we should allow a single endpoint to return both highlevel and lowlevel information, or if we should keep these endpoints independent.

              Features that should be selectable:

              lowlevel.average_loudness, lowlevel.dynamic_complexity, metadata.audio_properties.replay_gain, rhythm.beats_count, rhythm.beats_loudness.mean, rhythm.bpm, rhythm.bpm_histogram_first_peak_bpm.mean, rhythm.bpm_histogram_second_peak_bpm.mean, rhythm.danceability, rhythm.onset_rate, tonal.chords_key, tonal.chords_scale, tonal.key_key, tonal.key_scale, tonal.tuning_frequency, tonal.tuning_equal_tempered_deviation

                    aidanlw17 Aidan Lawford-Wickham
                    alastairp Alastair Porter
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    2 Start watching this issue

                      Created:
                      Updated:
                      Resolved:

                        Version Package

                          aidanlw17 Aidan Lawford-Wickham
                          alastairp Alastair Porter
                          Votes:
                          0 Vote for this issue
                          Watchers:
                          2 Start watching this issue

                            Created:
                            Updated:
                            Resolved:

                              Version Package