Software help archive
Bug Serato 2.3.1: Track Id not updated during rescan.
Support
Bug Serato 2.3.1: Track Id not updated during rescan.
A read-only archive of old serato.com help threads.
Bug Serato 2.3.1: Track Id not updated during rescan.
Product
Scratch Live
Version
2.3.1
Hardware
Rane SL1
Computer
PC
OS
Platform
-
pueblofunky
3:17 PM - 10 November, 2011
Hi,
1. I'd stored the track id (TRCK) in a WAV (!) file. Imported in Serato 2.3.1.
2. I've deleted the TRCK value with Tag & Rename 3.5.7. Looked into the WAV file with HxD and the value (ID3 tag) is really removed.
3. Started a rescan in Serato 2.3.1 and it still shows the value. = BUG
4. Deleted the track in Serato and re-imported it: OK
Please fix this bug.
Until the fix I always have to re-import my whole library in Serato because I also make changes in Tag & Rename.
btw: I'm using the track# for the discogs release id# ... so it's an important value. ;-)
1. I'd stored the track id (TRCK) in a WAV (!) file. Imported in Serato 2.3.1.
2. I've deleted the TRCK value with Tag & Rename 3.5.7. Looked into the WAV file with HxD and the value (ID3 tag) is really removed.
3. Started a rescan in Serato 2.3.1 and it still shows the value. = BUG
4. Deleted the track in Serato and re-imported it: OK
Please fix this bug.
Until the fix I always have to re-import my whole library in Serato because I also make changes in Tag & Rename.
btw: I'm using the track# for the discogs release id# ... so it's an important value. ;-)
Shaun W
5:03 PM - 10 November, 2011
Quick question, does rescanning the ID3 tag for those "Tagged and Renamed" tracks update what SSL displays within your library?
Does loading the track to a deck update SSLs library display?
Does loading the track to a deck update SSLs library display?
pueblofunky
1:59 PM - 11 November, 2011
No - a rescan does not work in SSL. Of course in Tag & Rename. As I said: I've checked the WAV file with a hex dump and the ID3 tag does not exist anymore. SSL 2.3.1 still shows the "cache".
I've reported a bug earlier regarding this (and WAV files) for another field and it has been fixed. Maybe this bug still exists with the field TRCK because it's a "read-only" tag in SSL 2.3.1 (which hopefully changes soon!).
I've never used the field TRCK before. Just moved all from TPOS (Disc# - not supported by SSL 2.3.1 :-( ) to TRCK to see the "discogs release id" (which I'd stored in this column) in SSL.
Loading the track to the stand-alone-player does not update the data in SSL. I'm sure also not if I would connect SL1.
--
Also tried an analyze. TRCK not updated in SSL.
Also changing another field in SSL 2.3.1 on a tag&rename changed track - does not updated the TRCK value in the file but still shown in SSL 2.3.1 library view. THX - otherwise I would have a chaos with the data.
The only one solution to have correct data would be to re-import infected files which means all my 17.000 tracks after some changes.
So this bug has to be fixed with the next release. Note: Done with WAV - not a MP3.
Quote:
Quick question, does rescanning the ID3 tag for those "Tagged and Renamed" tracks update what SSL displays within your library?No - a rescan does not work in SSL. Of course in Tag & Rename. As I said: I've checked the WAV file with a hex dump and the ID3 tag does not exist anymore. SSL 2.3.1 still shows the "cache".
I've reported a bug earlier regarding this (and WAV files) for another field and it has been fixed. Maybe this bug still exists with the field TRCK because it's a "read-only" tag in SSL 2.3.1 (which hopefully changes soon!).
I've never used the field TRCK before. Just moved all from TPOS (Disc# - not supported by SSL 2.3.1 :-( ) to TRCK to see the "discogs release id" (which I'd stored in this column) in SSL.
Quote:
Does loading the track to a deck update SSLs library display?Loading the track to the stand-alone-player does not update the data in SSL. I'm sure also not if I would connect SL1.
--
Also tried an analyze. TRCK not updated in SSL.
Also changing another field in SSL 2.3.1 on a tag&rename changed track - does not updated the TRCK value in the file but still shown in SSL 2.3.1 library view. THX - otherwise I would have a chaos with the data.
The only one solution to have correct data would be to re-import infected files which means all my 17.000 tracks after some changes.
So this bug has to be fixed with the next release. Note: Done with WAV - not a MP3.
Shaun W
4:50 PM - 11 November, 2011
Are you able to manually delete the tag info using SSL? If so, does the deleted tag information remain deleted after restarting SSL?
pueblofunky
5:33 PM - 11 November, 2011
No - the field "track" is not editable in SSL 2.3.1 - but hopefully in the future.
Quote:
Are you able to manually delete the tag info using SSL? If so, does the deleted tag information remain deleted after restarting SSL?No - the field "track" is not editable in SSL 2.3.1 - but hopefully in the future.
Shaun W
5:58 PM - 11 November, 2011
Please upload one of those WAV files to this thread and I'll take a look at it.
Thanks!
Thanks!
pueblofunky
3:42 PM - 23 November, 2011
Hi Shaun,
sorry for delay.
I've prepared 2 audio WAV files:
"TrackNrChangeNotDetected_WithTrackNr.wav" contains the track number "123456789" and in field "album" the text "MyAlbumWith".
TrackNrChangeNotDetected_WithoutTrackNr.wav" contains no track number and in field "album" the text "MyAlbumWithout".
1. Copy the file "TrackNrChangeNotDetected_WithTrackNr.wav" into a test directory and rename the file into "Test.wav". Screen Shot "SSL231_TrackNrChangeNotDetected_1.png"
2. Import the file in SSL 2.3.1
3. Delete the file "Test.wav"
4. Copy the file "TrackNrChangeNotDetected_WithoutTrackNr.wav" into the test directory and rename the file into "Test.wav". This change is the same if I would edit the file with Track & Rename.
5. Select the imported file "Test.wav" from the library and move it over "Rescan ID3 tags". Screen Shot "SSL231_TrackNrChangeNotDetected_2.png"
As you can see the track number is still there, but the value of the field "album" has changed to "MyAlbumWithout". So the track number will not be re-scanned! = BUG.
6. Finally delete the track "Test.wav" from the library with ALT + DELETE and re-import the (new/updated) file again. Screen Shot "SSL231_TrackNrChangeNotDetected_3.png"
As you can see - there is no track number.
Please fix this bug in the next release. If possible please send me an invitation to the next Beta release.
Thx
sorry for delay.
I've prepared 2 audio WAV files:
"TrackNrChangeNotDetected_WithTrackNr.wav" contains the track number "123456789" and in field "album" the text "MyAlbumWith".
TrackNrChangeNotDetected_WithoutTrackNr.wav" contains no track number and in field "album" the text "MyAlbumWithout".
1. Copy the file "TrackNrChangeNotDetected_WithTrackNr.wav" into a test directory and rename the file into "Test.wav". Screen Shot "SSL231_TrackNrChangeNotDetected_1.png"
2. Import the file in SSL 2.3.1
3. Delete the file "Test.wav"
4. Copy the file "TrackNrChangeNotDetected_WithoutTrackNr.wav" into the test directory and rename the file into "Test.wav". This change is the same if I would edit the file with Track & Rename.
5. Select the imported file "Test.wav" from the library and move it over "Rescan ID3 tags". Screen Shot "SSL231_TrackNrChangeNotDetected_2.png"
As you can see the track number is still there, but the value of the field "album" has changed to "MyAlbumWithout". So the track number will not be re-scanned! = BUG.
6. Finally delete the track "Test.wav" from the library with ALT + DELETE and re-import the (new/updated) file again. Screen Shot "SSL231_TrackNrChangeNotDetected_3.png"
As you can see - there is no track number.
Please fix this bug in the next release. If possible please send me an invitation to the next Beta release.
Thx
pueblofunky
8:35 PM - 27 November, 2011
Is it please possible that someone from Serato or Rane can confirm this bug and fix it?
Thanks a lot.
Thanks a lot.
Samuel S
9:28 PM - 27 November, 2011
I can confirm this and will log it with the team. Hopefully this can be fixed in an upcoming release but I couldn't give a timeframe as to when it would be available sorry.
Thanks for the info!
Sam.
Thanks for the info!
Sam.