View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002633 | ardour | bugs | public | 2009-04-12 13:15 | 2020-04-19 20:13 |
| Reporter | tmennola | Assigned To | paul | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 3.0-beta1 | ||||
| Summary | 0002633: Timestamp not recognized when importing audio | ||||
| Description | When I try to import an existing audio file into a session, its timestamp is not correctly recognized when the imported file is placed in the session. Steps to reproduce: 1. Create a session and record some audio. Start the recording somewhere else than at the beginning of the session. 2. Export the recorded audio region. Make sure to set export format to BWF. 3. Close the session and create a new one. 4. Import the exported file into the new session. Select "use file timestamp" in the Insert: selection box. The desired result would be that the imported file appears at the location determined by the timestamp. However, what happens is that the file appears at the beginning of the session, as if there had been no timestamp in the file. Also, when the imported region appears in the Regions list, its start position is given as 001|01|0000, regardless of what the original timestamp was. I have tried both "to selected tracks" and "as new tracks" in the Add files: selection box. I have also tried launching the import dialog in various ways (Session->Import, right-click on a track, right-click on the Region list), but the outcome is always the same. The correct timestamp is however shown in the Timestamp: field of the Add existing media dialog, so I do not believe there is anything wrong with the file that I try to import. I have also checked the file with sndfile-info -b, and there seems to be correctly formed broadcast information present. The timestamp shown by sndfile-info is correct and matches with the timestamp shown in the dialog box in ardour. | ||||
| Additional Information | Ardour 3.0 built from revision 4920 Ubuntu Studio 8.10 | ||||
| Tags | No tags attached. | ||||
| related to | 0002605 | closed | paul | [PATCH] Use file timestamp when importing broadcast wave files |
| related to | 0003065 | closed | oofus | Imported files always get placed at the playhead regardless of selected options. |
| parent of | 0002976 | closed | paul | Use file timestamp for import places files at the wrong position if if sample rates don't match |
|
|
This is related to 0002605 and 0002976. It [partly] works when "linking" the input file rather than "copying" it (ardour3 - r6703). partly: because the file is imported at the correct position, but the context-menu-function "move file to original position" always moves it to 00:00:00. One part of the problem is that the timestamp is garbled when ardour imports the file: Check the imported files <ardour-session>/interchange/*/audiofiles/ with 'sndfile-info -b'. |
|
|
this should be checked in ardour2 - i believe this has been fixed there, but the fix has not (yet) been forward ported to ardour3. there are about 160 commits to ardour2 that need to be applied to ardour3. |
|
|
It works fine in ardour 2.8.8 but not in SVN 3.0. |
|
|
Timestamps not working for me in Mixbus 1.2 (Ardour 2.8.8). Using BWF exported from Digital Performer. |
|
|
The issue in mixbus has been fixed already (caused by using Apple libraries for handling audiofiles, which don't make timestamp info available). The fix will be in the next release of Mixbus. Ardour 2.8.8 has not yet been released, and it will not suffer from the issue that showed up in Mixbus 1.2. |
|
|
x42: this should have been fixed in a3 some time ago. please confirm because i'd like to close the bug. |
|
|
I'm sorry to say, we're not done, yet. It basically works in A3 - verified with rev.7723. A few issue remain however: If files which are being resampled on import their offset is wrong (they're offset by the samples-count of the non-resampled file). Reproduce: import a 44100 SPS .wav file with bext header into a 48k Session. If the broadcast-header of the 44100 SPS files states an offset by 1:00:00 ardour's "original position" aka "sync-point (absolute)" of the imported file is going to be 0:55:07.15 (with 30FPS). An minor issue is that ardour [temporarily] remembers the sync point according to the Timecode-FPS setting that is active when importing the file. Reproduce: change Properties->Timecode from 30 to 25. Import the same file again. It will end up with its "sync-point" set to 0:55:07.12 . It's even possible to get invalid values (eg 00:00:07.29 in a 25FPS session). The value of the previously imported file retains the invalid value in "Region Properties" until one moves the region away and selects "Original Position". |
|
|
addendum: The last issue seems related to 3098. "Region Properties" should also be updated when changing the FPS. |
|
|
The sample-rate issue is also filed as 0002976 (SVN/2.0-ongoing). If you re-assign 0002967 to SVN 3.0, you can basically you can close this bug. |
|
|
see final comment, re 0002976. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-04-12 13:15 | tmennola | New Issue | |
| 2010-02-20 16:56 | x42 | Note Added: 0007381 | |
| 2010-02-25 17:06 | paul | Note Added: 0007384 | |
| 2010-02-25 17:38 | x42 | Note Added: 0007387 | |
| 2010-03-10 04:21 | rsanchez | Note Added: 0007405 | |
| 2010-03-14 15:02 | paul | Note Added: 0007407 | |
| 2010-04-18 00:14 | cth103 | Relationship added | related to 0002605 |
| 2010-04-18 00:14 | cth103 | Relationship added | parent of 0002976 |
| 2010-04-18 00:15 | cth103 | Relationship added | related to 0003065 |
| 2010-04-24 10:28 | cth103 | Category | bugs => bugs2 |
| 2010-04-24 10:29 | cth103 | Category | bugs2 => bugs |
| 2010-07-21 15:39 | cth103 | cost | => 0.00 |
| 2010-07-21 15:39 | cth103 | Target Version | => 3.0-beta1 |
| 2010-08-31 16:09 | paul | Note Added: 0008969 | |
| 2010-08-31 16:09 | paul | Status | new => feedback |
| 2010-08-31 19:07 | x42 | Note Added: 0008970 | |
| 2010-08-31 19:14 | x42 | Note Added: 0008971 | |
| 2010-09-01 11:49 | x42 | Note Added: 0008974 | |
| 2010-09-16 21:42 | paul | Note Added: 0009076 | |
| 2010-09-16 21:42 | paul | Status | feedback => resolved |
| 2010-09-16 21:42 | paul | Resolution | open => fixed |
| 2010-09-16 21:42 | paul | Assigned To | => paul |
| 2020-04-19 20:13 | system | Note Added: 0021893 | |
| 2020-04-19 20:13 | system | Status | resolved => closed |
