Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to Embedded WAV/AIFF Metadata Inside FLAC #59

Open
otristan opened this issue Mar 10, 2014 · 13 comments
Open

Access to Embedded WAV/AIFF Metadata Inside FLAC #59

otristan opened this issue Mar 10, 2014 · 13 comments
Labels

Comments

@otristan
Copy link

I have lots of wav/aiff files with embedded sample playback informations
that I read using SFC_GET_LOOP_INFO and SFC_GET_INSTRUMENT.

I would like that once those file are reencoded in flac (using --keep-foreign-metadata)
still be able to retrieve those informations as well as getting custom chunk
using sf_get_chunk_size and sf_get_chunk_data

@erikd
Copy link
Member

erikd commented Mar 14, 2014

Had a look at this. Currently looks like there is a bug in libFLAC with respect to application metadata.

@erikd
Copy link
Member

erikd commented Mar 14, 2014

Scratch that. I was misusing the FLAC metadata API (which is a little too easy to misuse).

@erikd
Copy link
Member

erikd commented Mar 15, 2014

Gah! This is getting complicated real fast. I can grab the application metadata chunk from FLAC, but I can't just pass it to the WAV header parse routines because they expect a file descriptor and I've got a pointer to a block of memory.

The solution is some significant refactoring as follows:

  • Set up a bunch of routines to parse blocks of memory with functions similar to psf_binheader_readf().
  • Convert wav_read_smpl_chunk() to work with this new block parsing function.
  • Call wav_read_smpl_chunk() from the src/flac.c with the metadata block.

@erikd erikd added the Wishlist label Jun 27, 2014
@mynameisjohn
Copy link

Not sure if this is still on the wishlist, but I wrote some code to get this data out of a file using the FLAC api
Function is here, some IO util functions are declared above
In my case I can use an istreambuf * because I have the file in memory, but I think it would be trivial to adapt that function to use variouse STL stream classes. This is pretty similar to setting up a SF_VIRTUAL_IO.

@jpcima
Copy link
Contributor

jpcima commented May 17, 2020

Set up a bunch of routines to parse blocks of memory with functions similar to psf_binheader_readf().

As an alternative, can we possibly read the whole binary chunk in one go, and then parse it with sfendian.h functions psf_get_le32? This seems less complicated than the refactor.

@jlearman
Copy link

Please fix this in the lib, so that programs like linuxsampler will be able to honor 'smpl' chunk loops. Any chance of this happening soon, or should they pursue a workaround like sfztools/sfizz#242 ?

@cschoenebeck
Copy link

The solution is some significant refactoring as follows:

* Set up a bunch of routines to parse blocks of memory with functions similar to psf_binheader_readf().

* Convert wav_read_smpl_chunk() to work with this new block parsing function.

* Call wav_read_smpl_chunk() from the src/flac.c with the metadata block.

AFAICS changing wav_read_smpl_chunk() is probably not necessary. It might make sense simply passing a temporary copy of SF_PRIVATE structure to wav_read_smpl_chunk() with SF_PRIVATE->vio being filled with custom seek/read functions which read from memory instead of doing real file I/O.

@cschoenebeck
Copy link

@erikd Would you mind sharing whatever you already had on this issue, so that we can complete your patch to fit into libsndfile appropriately? That would save us some work and would help to bring this issue forward.

@kmturley
Copy link

@zodf0055980 and @evpobr helped improve handling of SMPL chunks in WAV files. Perhaps they can help suggest how to implement this feature?

9113112

@evpobr
Copy link
Member

evpobr commented Oct 12, 2022

Soppy, no plans yet. But we will be happy to accept the patch.

@kmturley
Copy link

Oct. 19, 2022 - Version 12.49 release of exiftool now parses .wav and .flac loop data!
"Decode 'riff' metadata blocks in FLAC audio files"
https://exiftool.org/history.html

Usage:

exiftool ./har.wav
exiftool ./har.flac

Output:

Encoding                        : Microsoft PCM
Num Channels                    : 1
Sample Rate                     : 48000
Avg Bytes Per Sec               : 96000
Bits Per Sample                 : 16
Manufacturer                    : 0
Product                         : 0
Sample Period                   : 20833
MIDI Unity Note                 : 64
MIDI Pitch Fraction             : 0
SMPTE Format                    : none
SMPTE Offset                    : 00:00:00:00
Num Sample Loops                : 1
Sampler Data Len                : 0
Sampler Data                    : (Binary data 20 bytes, use -b option to extract)
Unshifted Note                  : 64
Fine Tune                       : 0
Gain                            : 0
Low Note                        : 0
High Note                       : 127
Low Velocity                    : 0
High Velocity                   : 127
Acidizer Flags                  : One shot
Root Note                       : High C
Beats                           : 2
Meter                           : 4/4
Tempo                           : 0
Comment                         : Recorded on 7/10/2022 in Edison.
Software                        : FL Studio 20
Duration                        : 0.87 s

@evpobr
Copy link
Member

evpobr commented Dec 29, 2022

Good. Can we close it now?

@kmturley
Copy link

@evpobr ah apologies for not providing context.

Exiftool is primarily used for inspecting files metadata after files have already been created.

Adding support in libsndfile would ensure creation of audio files with the correct metadata.

Exiftool can help whoever is working on this feature to validate it functions correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants