[6.43] Explode multichannel items disregards BWF start offset

paaltio · 12-28-2021, 07:14 AM

I'm not sure if this ever worked (in which case this is not technically a bug report I guess), but "Item: Explode multichannel audio or MIDI to new one-channel items" on a broadcast WAV file does not add a BWF start offset to the resulting files.

I think expected behavior would be to just copy the timestamp from the original (as opposed to the "point of explosion"), because this is not a render operation.

schwa · 12-28-2021, 07:18 AM

I suppose if the user has wav with bext enabled set as the glue/render format, not only the start offset but also other metadata should be preserved, although this is a bit complicated. We'll think about the best way to handle this.

paaltio · 12-28-2021, 09:56 AM

Quote:

Originally Posted by schwa

I suppose if the user has wav with bext enabled set as the glue/render format, not only the start offset but also other metadata should be preserved, although this is a bit complicated. We'll think about the best way to handle this.

Thanks for taking a look at it!

12-28-2021, 07:14 AM	#1
paaltio Human being with feelings Join Date: Aug 2011 Location: Los Angeles, CA Posts: 331	[6.43] Explode multichannel items disregards BWF start offset I'm not sure if this ever worked (in which case this is not technically a bug report I guess), but "Item: Explode multichannel audio or MIDI to new one-channel items" on a broadcast WAV file does not add a BWF start offset to the resulting files. I think expected behavior would be to just copy the timestamp from the original (as opposed to the "point of explosion"), because this is not a render operation.

12-28-2021, 07:18 AM	#2
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,115	I suppose if the user has wav with bext enabled set as the glue/render format, not only the start offset but also other metadata should be preserved, although this is a bit complicated. We'll think about the best way to handle this.